CST4708 & CST3604 Project 1: Auto Rental Management System Requirements

CST4708/CST3604 Project Assignment A Practical Approach to Application Development & using Theoretical Concepts & Hands-on Best Practices Auto Rental Point-of-Sales Management System Multi-Tiered Application Overview, Design & Implementation PROJECT #1 PART 2 Detailed Requirements – Database Design & Implementation Detailed Requirements (Part 2 of 3) Prof. Abel Angel Rodriguez

2 CST4708 & CST3604 PROJECT 1 – SRING 2023 Auto Rental Management System Application Requirements Section 5 – Project 1 Database Development Detailed Requirements (** CST4708 & CST3604 Database Developers, this Section Lists what Exactly you need to do and the order to do it! FOLLOW THESE REQUIREMENTS/STEPS EXACTLY AS INDICATED TO COMPLETE YOUR PROJECT! **) Section 5a – Execute Project Management Methodology Planning Phase SPRINT #1 Requirements #1 & #2 ❑ In this section, the Database Developer will execute the planning phase of the project and output the requires deliverable from this phase as indicated in this requirement. ❑ Overview of objectives, activities and deliverables for this phase are shown below: This Section Applies to Both CST4708 & CST3604 Classes. Any differences between the two classes will be identified.

3 PLANNING PHASE – The first phase is the planning phase. Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

4 Requirement #1 (4 POINTS) – Phase 1: Execute the Planning Phase & PROJECT DOCUMENT Deliverable  Requirement #1 – START OF SPRINT #1 ❑ In this requirement, you MUST EXECUTE requirements #1a through #1i as follows: ❖ Requirement #1a – [SPRINT #1] Plan the Creation of the Project Document : 1. Plan the creation of a Microsoft Word or other word processing program document . 2. Don’t create the document yet. First read requirements #1b, #1c & #1d so you can decide on a document template in MS Word or other processing program that works for you . 3. This document you are going to create is the Project Document that you will submit as your project deliverable and must include a COVER PAGE , TABLE OF CONTENT , TOP-PROJECT-SECTION-HEADER , and SUB-SECTIONS-HEADER for each REQUIREMENT in this PROJECT as indicated in requirements #1b, #1c & #1d . 4. This document is intended to contain all project plan , analysis , design & implementation information for this ENTIRE PROJECT 1 EXAM! THIS WILL BE YOUR PROJECT DOCUMENT THAT YOU WILL SUBMIT TO YOUR EMPLOYER (PROF RODRIGUEZ) SO HE CAN SUBMIT IT TO CUSTOMER EZ Rental Inc . 5. This document is to be CUSTOMER ready, which means it should be targeted for the customer (more on this in requirement #1c ). 6. If you wish, use one of the project templates from the word processing program or create your own project document format manually. 7. Requirement #1a Go Do #1 – Only after you have read requirements #1b, #1c & #1d , go ahead and CREATE the document using a template or custom built. 8. Give this file a name to reflect the project you are implementing. Use the following format for the name: Name_ EZRental POS Design & Implementation . Note that the name is your full name.

5 ❖ Requirement #1b (IMPORTANT REQUIREMENT FOR ENTIRE DOCUMENT!) – [SPRINT #1] Implement a professionally FORMATTED Document. Each section of the Document should include a SHORT PARAGRAPH explaining the section : 1. Implement a professionally looking document. 2. Every section of the document should be clearly labeled using HEADERS as will be indicated in this document. 3. IMPORTANT!! 1) Every section should contain a short paragraph explaining the section . Don’t just ADD the answers to a requirement without an explanation of what the content of each SECTION HEADER is. 2) The paragraph(s) for each SECTION should be short and describe WHAT THE SECTION IS AND WHAT WAS DONE . Keep your explanations short. 4. Your goal is to make it easy for the reader to understand from a high level what it is they are reading and what was done . 5. THIS DOCUMENT IS YOUR DELIVERABLE, and you will be PAID/GRADED ON HOW THIS DOCUMENT IS FORMATTED, AND THE ABILITY OF THE READER TO EASILY UNDERSTAND WHAT YOU HAVE DONE & HOW! ❖ Requirement #1c (IMPORTANT REQUIREMENT FOR ENTIRE DOCUMENT!) – [SPRINT #1] The Project document CONTENT/INFORMATION FOR EACH PARAGRAPH HAS TO BE CUSTOMER FOCUSED/CUSTOMER READY : 1. Don’t confuse this Project #1 REQUIREMENT DOCUMENT you are now reading, with the EZRental PROJECT DESIGN & IMPLEMENTATION DOCUMENT you are being asked to create. There are two different documents: 1) Project #1 Requirement Document – This document is what you are reading NOW, and contains the project statement, project management methodology, business requirements, design decisions and most important the Requirements #1 to Requirements #11 that are going to tell you what to do exactly. In addition, it contains some THEORY where Prof. Rodriguez is teaching you how to do the work! You can leverage the content written in this document along with a ZIP PACKAGE, that I will provide, and use it to create YOUR EZRental POS Design & Implementation Document but MODIFY THE CONTENT to be CUSTOMER READY by following the instructions in this Requirement #1c . 2) EZRental POS Design & Implementation Document – This is the document YOU ARE CREATING AND POPULATING that contains the results of the execution of the requirements listed in this Project #1 Requirement Document . This is the document you are creating in this REQUIREMENT #1 , must be customer ready to be submitted to the customer by Prof. Rodriguez, and you are being paid/graded on!

6 2. The EZRentalPOS Design & Implementation document contains the goals and requirements for the EZ Rental POS Management System . 3. IMPORTANT KEY POINT – This document is INTENDED to be SUBMITTED & READ BY THE CUSTOMER EZ Rental Inc., NOT your EMPLOYER Prof. Rodriguez! Therefore, MUST be created professionally & targeted to the customer AT THE END OF THE PROJECT, thus CUSTOMER READY! 4. The document explains WHAT WAS DONE, NOT WHAT YOU ARE GOING TO DO. Therefore, your verbiage in each paragraph should assume that when the customer is reading the document, it is after the project is completed and submitted to the customer for review. This means the wording in your paragraphs should be past tense and the information conveyed should be generalized and target the second or third- person point of view, NOT WHAT YOU ARE DOING NOW OR WILL BE DOING IN THE FUTURE BUT INSTEAD WHAT WAS DONE IN THE PAST! 5. DO NOT INCLUDE THE INSTRUCTIONS IN THIS DOCUMENT REQUIREMENTS OR REQUIREMENT # OR INSTRUCTIONS ON WHAT THIS REQUIREMENT DOCUMENT IS TELLING YOU TO DO!!! 6. KEEP IN MIND YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT, IS THE DELIVERABLE TO PROF. RODRIGUEZ TO SUBMIT TO THE CUSTOMER THAT CONTAINS THE PLAN, ANALYSIS, DESIGN & IMPLEMENTATION OF THE SOLUTION, NOT INSTRUCTIONS FROM THIS REQUIREMENTS DOCUMENT. This is what CUSTOMER READY means! 7. YES, YOU CAN LEVERAGE THE VERBIAGE AND SOME OF THE CONTENT THAT PROF. RODRIGUEZ HAS IN THIS Project #1 Requirement Document TO CREATE YOUR PARAGRAPHS, BUT THEY MUST BE MODIFIED TO TARGET THE CUSTOMER THUS CUSTOMER READY! 8. Here is a summary of the guidelines you should keep in mind when you create the content and paragraphs of this document to make it CUSTOMER READY: 1) Should be in past tense. 2) Should be written in third person perspective. 3) Don’t include the theory found in this Project Requirements Document. The Customer is NOT looking for a technical education, only WHAT & HOW NYC Tech Solutions executed the job the customer paid for! 4) Be clear, precise and to the point.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

7 ❖ Requirement #1d – [SPRINT #1] & CREATE DOCUMENT PAGE STRUCTURE & SECTION HEADERS as follows: 1. Requirement #1d Go Do #1 – In your Project Design and Implementation document CREATE a COVER PAGE (this will be the first page of the document) . 2. Go Do #2 – CREATE a Table of Content (this will be your second page of the document) . 3. Go Do #3 – In your third page , ADD a TOP-PROJECT-SECTION-HEADER at the beginning or TOP of the third page . This will be your main section header for PROJECT #1 . Name this TOP-PROJECT-SECTION-HEADER using VERY LARGE FONT as follows: PROJECT 1 – EZRental Auto Rental POS Management System Database Design and Implementation 4. Go Do #4 – Also on the third page , ADD a SUB-SECTION-HEADERS named Executive Summary immediately after the TOP-PROJECT-SECTION-HEADER at the top of the page . Use a slightly SMALLER FONT than the TOP-PROJECT-SECTION-HEADER , for example: Executive Summary 5. Go Do #5 – Starting on the fourth page , CREATE 16 SUB-SECTION-HEADERS one on TOP OF EACH PAGE, for a total of 17 SUB-SECTION-HEADER including the Executive Summary sub-section- header of page 3. Important! All the remaining 16 SUB-SECTION-HEADERS starting on page 4, must reside ON TOP OF each PAGE OF EACH SUB-SECTION-HEADER. NO SUB-SECTION-HEADER in the middle or anywhere else on a page but on the TOP! Leave the rest of each page blank for now. 6. Below is the structure of ALL the SECTIONS of the document and the ORDER (note that the sub- section header numbers shown below are not required in your document, it is up to you): PROJECT 1 – EZRental Auto Rental POS Management System Database Design and Implementation 1. Executive Summary 2. Problem Statement & Objectives 3. Project Management Methodology 4. Database Design Deliverable #1a – Application Business requirements 5. Database Design Deliverable #1b – Application Development Technical Requirements 6. Application Physical Technical Architecture 7. Application Development Features and Functionalities (Agile Backlog) 8. Database Management System Development Environment & Physical Architecture 9. Project Roles & Responsibilities 10. Database Design Deliverable #2 – ER/EER Conceptual Model Diagram 11. Database Design Deliverable #3 – Normalized Logical Model Diagram 12. Database Design Deliverable #4 – Physical Model Data Dictionary 13. Database Design Deliverable #5 – Physical Model Schema Design Diagram 14. Database Implementation Deliverable #6 – Development & Implementation 15. Database Implementation Deliverable #7 – Implemented Physical Schema Diagram 16. Database Implementation Deliverable #8 – Database Validation Testing 17. Conclusion

8 ➢ At the end of Requirement #1d, the structure and order of section headings for the EZRental POS Project Design and Implementation document should be follows: ➢ IMPORTANT! Each of the SUB-SECTION-HEADERS pages are BLANK at this point, and the reason is there are 19 pages. Nevertheless, each subsection will be POPULATED based on content indicated in Requirements #1 to Requirement #11 of this document, therefore the number of pages will increase significantly in the future.

9 ❖ Requirement #1e – [SPRINT #1] OVERVIEW ON CONTENT YOU NEED TO ADD for SUB-SECTION-HEADERS 1 through 9 as follows of your Project Design & Implementation Document: 1. The first 9 SUB-SECTION-HEADERS of the EZRental POS Project Design and Implementation document set up the reader with an overall picture of the application and the derived Design and approach on how it is going to be done from the Business & Technical Requirement : 1) Executive Summary 2) Problem Statement & Objectives 3) Project Management Methodology 4) Application Business requirements 5) Application Development & Technical Requirements 6) Application Physical Technical Architecture 7) Application Development Features and Functionalities (Agile Backlog) 8) Database Management System Development Environment & Physical Architecture 9) Project Roles & Responsibilities 2. IMPORTANT – The PARAGRAPH CONTENT & IMAGES you will need to POPULATE these 9 SUB- SECTION-HEADERS , in your EZRental POS Project Design and Implementation document, are found in the following two places: 1) This Project #1 Requirement Document SECTIONS 1 through 4 . ▪ You are to leverage all content from this Project #1 Requirement Document as needed. ▪ Since you will have a PDF version of this Project #1 Requirement Document all you would ONLY be able to leverage is the TEXT from this document and you can HIGHLIGHT & COPY/PASTE to your EZRental POS Project Design and Implementation document . ▪ The images from this PDF Project #1 Requirement Document you CANNOT COPY , therefore I provided a ZIP FOLDER PACKAGE which contains IMAGES and WORD DOCUMENTS that includes TEXT & IMAGES you can leverage for content. ▪ Details of the ZIP FOLDER PACKAGE is described in next step.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

10 2) As indicated in the previous step, for additional content, I will provide you with a PROJECT 1 DOCUMENTS AND RESOURCES FOLDER PACKAGE (ZIP PACKAGE) which contains individual IMAGES and WORD DOCUMENTS that includes both TEXT & IMAGES you can leverage. This ZIP PACKAGE is divided into images used both by CST4708 & CST3604, and content specific to each of these classes. The ZIP PACKAGE contains the following STRUCTURED & CONTENT : a. ( Both CST4708 & CST3604 ) Images from this Project #1 Requirement Document SECTIONS 1 through 4 such as : ‐ Auto_Rental_EER_Model (JPG file) – Image of the EER Conceptual Model Diagram which is a diagram of the business data that needs to be captured by the application and their relationship. This diagram was designed by the Database Analyst/Architect derived from the Business Requirements. Simply COPY/PASTE to your EZRental POS Project Design and Implementation document as needed. ‐ Auto_Rental_Normalized_Logical_Model (JPG file) – Image of the Normalized Logical Diagram which is a diagram of the RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS) tables and relationships that will be needed for the Application. This diagram is a transformation of the EER Model converted to a Logical Model and then NORMALIZED using the 3-Normal Form Method . Simply COPY/PASTE to your EZRental POS Project Design and Implementation document as needed . ‐ Auto_Rental_Normalized_Logical_Model_PILOT_Deployment (JPG file) – Image of the PILOT sub-section of the full Normalized Logical Diagram. This will be the actual tables and relationships to design & implement in PROJECT #1. Simply COPY/PASTE to your EZRental POS Project Design and Implementation document as needed .

11 b. ( Both CST4708 & CST3604 ) 4 MS Word documents with data from this Project #1 Requirement Document SECTIONS 1 through 4 containing the following: ‐ Business_Technical_Requirements Document (DOCX file) – Word Document that contains the business and technical requirements for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ‐ Project_Management_Methodology Document (DOCX file) – Word Document that contains the Project Management Methodology requirements for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ‐ Application_Backlog_Features_Functionality Document (DOCX file) – Word Document that contains the entire List of features or Agile Backlog for the Application for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ‐ Roles_Responsibility Document (DOCX file) – Word Document that contains text and two tables summarizing the ROLES and RESPONSIBILITIES used for both the Back-End Database Design & Implementation, the Client Application and the Web Client Application for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY .

12 c. ( CST3604 ONLY ) A Folder containing Images & MS Word documents from Project #1 Requirement Document with content specifically targeted for CST3604 Class. This folder contains the following content: ‐ CST3604 SPRINT #1 SUB-FOLDER: ➢ CST3604_Client_Server_Physical_Architecture (JPG file) – Image of the entire Client/Server Physical Architecture using Oracle Server as the Back-End Database Management System (DBMS) for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ➢ CST3604_Oracle_DBMS_Server_Application (JPG file) – Image of only the Oracle DBMS Server Back-End Database Management System (DBMS) part of the Application for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ➢ CST3604_Oracle_Standalone_Development_Environment (JPG file) – Image of only the Oracle DBMS Server Back-End Database Management System (DBMS) part of the Application for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ‐ CST3604 SPRINT #2 SUB-FOLDER: ➢ CST3604_Data_Dictionary_Template (DOCX file) – Word Document that contains a list of empty Oracle Data Dictionary tables for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . These empty Dictionary Tables will be needed in SPRINT #2 and out of scope of SPRINT #1.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

13 d. ( CST4708 ONLY ) A Folder containing Images & MS Word documents from Project #1 Requirement Document with content specifically targeted for CST4708 Class. This folder contains the following content: ‐ CST4708 SPRINT #1 SUB-FOLDER: ➢ CST4708_Client_Server_Physical_Architecture (JPG file) – Image of the entire Client/Server Physical Architecture using MS SQL Server as the Back-End Database Management System (DBMS) for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ➢ CST4708_MS_SQL_Server_DBMS_Server_Application (JPG file) – Image of only the MS SQL Server DBMS Server Back-End Database Management System (DBMS) part of the Application for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ➢ CST4708_MS_SQL_Server_Standalone_Development_Environment (JPG file) – Image of only the MS SQL Server DBMS Server Back-End Database Management System (DBMS) part of the Application for you to simply COPY/PASTE as needed to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . ‐ CST4708 SPRINT #2 SUB-FOLDER: ➢ CST4708_Data_Dictionary_Template (DOCX file) – Word Document that contains a list of empty MS SQL Server Data Dictionary tables for you to simply COPY/PASTE what you need to your EZRental POS Project Design and Implementation document & modify by making it CUSTOMER READY . These empty Dictionary Tables will be needed in SPRINT #2 and out of scope of SPRINT #1.

14 3. In Summary, you will need to COPY/PASTE the CONTENT from this Project #1 Requirement Document and CONTENT from the ZIP FOLDER PACKAGE to POPULATE these first 9 SUB-SECTION- HEADERS of your Project #1 Requirement Document . 4. Requirement #1e Go Do #1 – BELOW are the detailed step-by-step instructions on POPULATING these first 9 SUB-SECTION-HEADERS : 1) Executive Summary: 1. This sub-section contains the Executive Summary for this Document . The executive summary is a paragraph(s) that includes: 1) what is the problem or need you need the document is solving, 2) outline of recommended solution(s), and 3) wraps up with a conclusion about the importance of the work. 2. You can leave this section blank and complete it at the end of Sprint #4 validation phase just before you are ready to submit the project. If you like, you can provide temporary content or overview of this Project1 document based on all the sections we are creating and finalizing at the end of the project . Up to you! 2) Problem Statement & Objectives: 1. This sub-section explains the problem you are trying to solve and the objective of the project. 2. This section must contain a few paragraphs with description and details on the objective of the project and expected outcome. In other words, APPLY Requirements #1b . How to do this is shown next. 3. Go Do #1 – COPY/PASTE the objectives paragraph(s) listed in this Project #1 Requirement Document problem statement section 1 page 1 but MODIFY the wording to target the customer or written in second/third person point of view. In other words, APPLY Requirements #1c . 3) Project Management Methodology: 1. This sub-section describes the project management methodology used in the project to make sure the Project is successful. 2. This section must contain one or more paragraph(s) that provides an overview of the project management methodology used in the project as per Requirements #1c . How to do this is shown next. 3. You should not have to create these paragraphs yourself, but leverage SOME of the CONTENT (paragraphs , images , etc .), I added to this Project #1 Requirement Document in the Project Management Methodology SECTION #1 . You don’t need to COPY ENTIRE SECTION 1 of this document. Just put together one paragraph and leverage one or a few of the images. The idea is you want to show a high-level view of both PM Methodology (Waterfall & Agile). 4. Go Do #1 – From the Project Management document in the ZIP FOLDER PACKAGE , OPEN the Application Project Management Methodology Document and COPY/PASTE this section your PARAGRAPH(S) and IMAGES of your choice for your EZRental Project Design and Implementation document . Decide which paragraphs and images to use to build your story for the customer who is going to read this document. 5. Go Do #2 – Make sure it is CUSTOMER READY by MODIFYING the paragraphs wording to target the customer or written in second/third person point of view. In other words, APPLY Requirements #1c .

15 4) Database Design Deliverable #1a – Application Business requirements : 1. This sub-section describes the Business Requirements that are driving the Database Design for this project. This section must contain a short paragraph that describes what this section is and must be customer ready, in other words, APPLY Requirements #1b & 1c . 2. Go Do #1 – IMPORTANT! To POPULATE this Application Business Requirements sub- section , follow the steps in Requirement #2 (2A & 2B) of this Project #1 Requirement Document located in this SECTION 5A in pages to follow . 5) Database Design Deliverable #1b – Application Development Technical Requirements : 1. This sub-section describes the Business Requirements that are driving the Database Design for this project. This section must contain a short paragraph that describes what this section is and must be customer ready, in other words, APPLY Requirements #1b & 1c . 2. Go Do #1 – IMPORTANT! To POPULATE this Application Development & Techincal Requirements sub-section , follow the steps in Requirement #2 (#2C & 2D) of this Project #1 Requirement Document located in this SECTION 5A in pages to follow . 6) Application Physical Technical Architecture: 1. This sub-section contains the full Client/Server Architectures decided by the architects for the Rental Agencies , Corporate Offices & Customer Internet Applications . 2. This section must contain a short paragraph that describes the application physical technical architecture requirements for the project. In other words, APPLY Requirements #1b . How to do this is shown next. 3. Go Do #1 – Create the paragraph(s) for this application physical technical architecture section, COPY/PASTE the paragraph found in this Project #1 Requirement Document in SECTION 4A , in the Application Physical Technical Architecture sub-section., but MODIFYING the paragraphs wording to target the customer or written in second/third person point of view. In other words, APPLY Requirements #1c . 4. Go Do #2 – COPY/PASTE the Application Physical Technical Architectures IMAGE from either CST4708 or CST3608 folder in the ZIP FOLDER PACKAGE for your specific class and COPY/PASTE this sub-section of your document.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

16 7) Application Development Features and Functionalities (Agile Backlog): 1. This sub-section describes the List of Feature & Functionality of the Application. This is known as the Agile Backlog . 2. This sub-section must contain a short paragraph that describes the Application Features & Functionality for the project. In other words, APPLY Requirements #1b . How to do this is shown next. 3. Go Do #1 – CREATE the paragraph(s) for the Feature & Functionality of the Agile Backlog sub-section and MODIFYING the paragraphs wording to target the customer or written in second/third person point of view as per Requirements #1c . 4. Go Do #2 – OPEN the Application_Backlog_Features_Functionality Word Document in the ZIP FOLDER PACKAGE to COPY/PASTE its content to meet the requirements for this section. 8) Database Management System Development Environment & Physical Architecture: 1. This sub-section describes the Database Management System & the Lab Environment Requirements you need to setup to implement the Database Server Application . 2. This sub-section must contain a short paragraph that describes the Database Management System & the Lab Environment Requirements for the project. In other words, APPLY Requirements #1b . How to do this is shown next. 3. Go Do #1 – CREATE the paragraph(s) for the Database Management System & the Lab Environment Requirements sub-section and MODIFYING the paragraphs wording to target the customer or written in second/third person point of view as per Requirements #1c . 4. Go Do #2 – COPY/PASTE the Standalone Development Environment IMAGE in the ZIP FOLDER PACKAGE to this section after the paragraph etc. 9) Project Roles & Responsibilities: 1. This sub-section describes the Roles and Responsibilities for the development and project management team engaged in the design, development & implementation of the entire application . The roles & responsibilities are divided into two groups, 1) the Database Architects & Database Developers responsible for designing and implementing the database, and 2) the Application & Web Developers responsible for the development and programming of the Windows and Web Applications . 2. This section must contain a short paragraph that describes the roles & responsibility for the members of the project. In other words, APPLY Requirements #1b . How to do this is shown next. 3. Go Do #1 – OPEN the Roles & Responsibility document in the ZIP FOLDER PACKAGE , COPY/PASTE the roles and responsibility paragraph(s) for the Database Management System (DBMS) resource sections and the Windows & Web Application resources. 4. Go Do #2 – MODIFY the paragraphs wording to target the customer or written in second/third person point of view as per Requirements #1c . 5. Go Do #3 – COPY/PASTE the roles and responsibility tables from the ZIP FOLDER PACKAGE file but MODIFY the wording to target the customer or written in second/third person point of view. In other words, APPLY Requirements #1c .

17 5. Reminder :  Requirement #1b – Every section should contain a short paragraph(s) explaining each sub-section in addition to required images as indicated above .  Requirement #1c – this document is INTENDED TO BE SUBMITTED TO THE CUSTOMER EZ Rental Inc., therefore MUST be created professionally & wording targeted to the customer, NOT NYC-TECH, Professor Rodriguez, YOU, or anyone else but the CUSTOMER .

18 ❖ Requirement #1f – [SPRINT #1] For the CONTENT of SUB- SECTION-HEADERS 10 & 11 READ the following instructions: 1. The content of SUB-SECTION HEADERS 9 & 10 is listed in Requirements #3 & #4 of this Project #1 Requirement Document . 2. See the instructions below to populate these sections: 10) Database Design Deliverable #2 – ER/EER Conceptual Model Diagram : 1. This sub-section describes the FIRST DATABASE DESIGN DELIVERABLE of the Waterfall Methodology ANALYSIS PHASE or the Data Modeling ER/EER Diagram . This diagram is DERIVED by the Database Analyst/Architect from the Application Business Requirements , which is the foundation of the Database Design for the Auto Rental Database Application (If interested in learning more in the future, see CST3504 Database Design Course Lectures to learn the steps for this process . ) . 2. Go Do #1 – IMPORTANT! To POPULATE this Database Design Deliverable #1 – ER/EER Conceptual Model sub-section , follow the steps in Requirement #3A, 3B & 3C of this Project #1 Requirement Document located in this SECTION 5B in pages to follow .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

19 11) Database Design Deliverable #3 – Normalized Logical Model Diagram : 1. This sub-section describes the THIRD DATABASE DESIGN DELIVERABLE which is the is the Normalized Logical Model Diagram . This diagram is the First Component of our Waterfall Methodology DESIGN PHASE . The PHYSICAL MODEL DESIGN PHASE is divided into the following 3 components which include the focus of this sub-section is the Normalized Logical Model Diagram : a) The Normalized Logical Model Diagram . b) The Physical Model Data Dictionary . c) The Physical Model Schema Design Diagram . d) Technical Specifications for performance, efficiency, data integrity, security, disaster recovery etc . 2. The Normalized Logical Model Diagram is derived using the following 2 steps by the Database Analyst/Architect : a) TRANSFORM the Data Modeling ER/EER Diagram to a Logical Model Diagram which converts the ER/EER Diagram into database tables (If interested in learning more in the future, see CST3504 Database Design Course Lectures to learn the steps for this process . ) . b) NORMALIZE the Logical Model Diagram using the 3-Normal Forms Rules to create the Normalized Logical Model Diagram (If interested in learning more in the future, see CST3504 Database Design Course Lectures to learn the steps for this process . ) . 3. IMPORTANT! Note that in this sub-section , we will list three diagrams: 1) The full Normalized Logical Model Diagram . 2) A Limited Pilot Logical Model Diagram . The Limited Pilot Logical Model Diagram is a SUB-SECTION of the full Normalized Logical Model Diagram , that includes only 13 tables . In real-world projects, the project management methodology may use a PILOT PHASE where a smaller version of the deliverables is deployed to production and used by a small set of pilot users. After all the bugs are fixed and the application is working for the PILOT USERS , then the FULL IMPLEMENTATION is deployed to the entire organization. 3) Finally, a PROOF-OF-CONCEPT (POC) Logical Model Diagram , that will be used for a PROTOTYPE of the application that will be implemented to demo a prototype to the business. The POC Logical Model Diagram is a SUB-SECTION of the full Normalized Logical Model Diagram , that includes only 4 tables . 4. Go Do #1 – IMPORTANT! To POPULATE this Database Design Deliverable #2 – Normalized Logical Model Diagram sub-section , follow the steps in Requirement #4 (4A, 4B, 4C, 4D, 4E & 4F) of this Project #1 Requirement Document located in this SECTION 5C in pages to follow .

20 ❖ Requirement #1g – [SPRINT #1] SPRINT #1 DELIVERABLE REQUIREMENTS – What & How to Submit in this SPRINT: 1. Is important that you submit your SPRINT #1 based on the requirements listed in Requirements #11b of SECTION 6 – PROJECT 1 DELIVERABLES . 2. Follow the instructions in Requirements #11b exactly as indicated.  Requirement #1 – END OF SPRINT #1  STOP HERE if Executing SPRINT #1

21  Requirement #1 – START OF SPRINT #2  START Here if Executing SPRINT #2 ❖ Requirement #1h – [SPRINT #2 ONLY] For the CONTENT of SUB- SECTION-HEADERS 12 & 13 READ the following instructions: 1. The content of SUB-SECTION HEADERS 11 & 12 is listed in Requirements #5 & #6 of this Project #1 Requirement Document . 2. IMPORTANT! These sections are OUT OF SCOPE FOR SPRINT #1 . Below instructions are for overview of this sub-section , but NOT TO BE EXECUTED IN SPRINT #1 . 3. To populate these sections, see below: 12) Database Design Deliverable #4 – Physical Model Data Dictionary : 1. As stated in the previous sub-section , the PHYSICAL MODEL DESIGN PHASE is divided into the following 3 components: a) The Normalized Logical Model Diagram . b) The Physical Model Data Dictionary . c) The Physical Model Schema Design Diagram . d) Technical Specifications for performance, efficiency, data integrity, security, disaster recovery etc . 2. This sub-section describes the FOURTH DATABASE DESIGN DELIVERABLE the Physical Model Data Dictionary . The Physical Model Data Dictionary is the Second Component of our Waterfall Methodology DESIGN PHASE PHYSICAL MODEL DESIGN! 3. The Physical Model Data Dictionary – is a TABULAR LISTING ( Column Name , Column Database Data Type , Column Constraints & Column Description ) FOR ALL THE COLUMNS OF EVERY TABLE IN THE Normalized Logical Model Diagram . Creating this tabular listing is part of the design process executed by the Database Developer . 4. Go Do #1 – IMPORTANT! To POPULATE this Database Design Deliverable #3 – Physical Model Data Dictionary sub-section , follow the steps in Requirement #5 of this Project #1 Requirement Document located in this SECTION 5D in pages to follow .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

22 13) Database Design Deliverable #5 – Physical Model Schema Design Diagram: 1. As has been stated in the previous sub-sections , the PHYSICAL MODEL DESIGN PHASE is divided into the following 3 components: a) The Normalized Logical Model Diagram . b) The Physical Model Data Dictionary . c) The Physical Model Schema Design Diagram . d) Technical Specifications for performance, efficiency, data integrity, security, disaster recovery etc . 2. This sub-section describes the FIFTH DATABASE DESIGN DELIVERABLE is the Physical Model Data Dictionary which is the third Component of our Waterfall Methodology DESIGN PHASE PHYSICAL MODEL DESIGN! This is a very important deliverable whose purpose and creation are as follows: a) WHAT IS IT? – The Physical Model Schema Design Diagram is the DESIGN of what the PHYSICAL Database or DBMS tables and their relationships will look like . This diagram is created by combining the Normalized Logical Model Diagram with the Physical Model Data Dictionary to create a NEW DIAGRAM called the Physical Model Schema Design Diagram . (If interested in learning more in the future, see CST3504 Database Design Course Lectures to learn the steps for this process . b) PURPOSE – The Physical Model Schema Design Diagram is the DIAGRAM USED TO IMPLEMENT THE DATABASE in the DBMS APPLICATION . THIS DIAGRAM SUMARIZES THE TABLES & RELATIONSHIPS REQUIRED TO IMPLEMENT THE DATABASE in the DBMS APPLICATION . 3. Go Do #1 – IMPORTANT! To POPULATE this Database Design Deliverable #4 – Physical Model Schema Design Diagram sub-section , follow the steps in Requirement #6A, #6B, #6C & #6D of this Project #1 Requirement Document located in this SECTION 5B in pages to follow . 4. ATTENTION! Note that the fourth Component of our Waterfall Methodology DESIGN PHASE PHYSICAL MODEL DESIGN , which is the Technical Specifications for performance, efficiency, data integrity, security, disaster recovery etc. , is out of scope of this PROJECT #1 and will ONLY be covered in CST3604 Class after Project #1 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

23 ❖ Requirement #1i – [SPRINT #2] SPRINT #2 DELIVERABLE REQUIREMENTS – What & How to Submit in this SPRINT: 1. Is important that you submit your SPRINT #2 based on the requirements listed in Requirements #11c of SECTION 6 – PROJECT 1 DELIVERABLES . 2. Follow the instructions in Requirements #11c exactly as indicated.  Requirement #1 – END OF SPRINT #2  STOP HERE if Executing SPRINT #2

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

24  Requirement #1 – START OF SPRINT #3  START HERE if Executing SPRINT #3 ❖ Requirement #1j – [SPRINT #3 ONLY] For the CONTENT of SUB- SECTION-HEADERS 14 & 15 READ the following instructions: 1. The content of SUB-SECTION HEADERS 13 & 14 is listed in Requirements #7 & #8 of this Project #1 Requirement Document . 2. IMPORTANT! These sections are OUT OF SCOPE FOR SPRINT #1 & SPRINT #2 . The instructions described in this sub-section ARE NOT TO BE EXECUTED IN SPRINT #1 OR #2 . 3. See the instructions below to populate these sections: 14) Database Implementation Deliverable #6 – Development & Implementation: 1. This sub-section describes the SIXTH DATABASE DELIVERABLE of the database design and implementation process, which is the Database Implementation Phase or implementing the Database . 2. This sub-section describes the requirements and steps to IMPLEMENT/CREATE the DATABASE APPLICATION using Database Design Deliverable #4 – Physical Model Schema Design Diagram in addition to ORACLE DBMS CREATE TABLE STATEMENTS to CREATE every TABLE & RELATIONSHIP listed in the Physical Model Schema Design Diagram . When all tables & relationships are created, the Database Application Development is completed . 3. Go Do #1 – IMPORTANT! To POPULATE this Database Implementation Deliverable #5 – Development & Implementation sub-section , follow the steps in Requirement #7A, #7B, #7C, #7D & #7E of this Project #1 Requirement Document located in this SECTION 5E in pages to follow .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

25 15) Database Implementation Deliverable #7 – Implemented Physical Schema Diagram: 1. This sub-section describes the SEVENTH DATABASE DELIVERABLE of the database design and implementation process, which to GENERATE/EXPORT the Implemented PHYSICAL SCHEMA DIAGRAM from the Database . 2. This Implemented Physical Schema Diagram is an EXPORTED DIAGRAM of every TABLE & RELATIONSHIP the was CREATE using the ORACLE DBMS CREATE TABLE STATEMENTS . This diagram should be an EXACT REPLICA of the Database Design Deliverable #4 – Physical Model Schema Design Diagram since it was created from this design diagram of requirement #6. If these the Implemented PHYSICAL SCHEMA DIAGRAM exported from the Database does NOT MATCH, the Database Design Deliverable #4 – Physical Model Schema Design Diagram , then there was an ERROR in the implementation! 3. Go Do #1 – IMPORTANT! To POPULATE this Database Implementation Deliverable #6 – Implemented Physical Schema Diagram sub-section , follow the steps in Requirement #8A, #8B, #8C, #8D, #8E & #8F of this Project #1 Requirement Document located in this SECTION 5E in pages to follow . ❖ Requirement #1k – [SPRINT #3] SPRINT #3 DELIVERABLE REQUIREMENTS – What & How to Submit in this SPRINT: 1. Is important that you submit your SPRINT #3 based on the requirements listed in Requirements #11d of SECTION 6 – PROJECT 1 DELIVERABLES . 2. Follow the instructions in Requirements #11d exactly as indicated.  Requirement #1 – END OF SPRINT #3  STOP HERE if Executing SPRINT #3

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

26  Requirement #1 – START OF SPRINT #4  START HERE if Executing SPRINT #4 ❖ Requirement #1l – [SPRINT #4 ONLY] For the CONTENT of SUB- SECTION-HEADERS 16 READ the following instructions: 1. The content of SUB-SECTION HEADERS 15 is listed in Requirements #9 of this Project #1 Requirement Document . 2. IMPORTANT! These sections are OUT OF SCOPE FOR SPRINT #1, SPRING #2 & SPRINT #3 . Below instructions are for overview of this sub-section , but NOT TO BE EXECUTED IN SPRINT #1, #2 OR #3 . 3. See the instructions below to populate this section: 16) Database Implementation Deliverable #8 – Database Validation Unit Testing: 1. This sub-section describes the EIGHTH DATABASE DELIVERABLE of the database design and implementation process, which is the Database Validation Unit Testing . 2. In this sub-section , TESTING & VALIEDATION is done by identifying a sub-set of the Implemented Physical Schema and executing SELECT, INSERT, UPDATE & DELETE statements to validate . 3. Go Do #1 – IMPORTANT! To POPULATE this Database Implementation Deliverable #7 – Database Validation Unit Testing sub-section , follow the steps in Requirement #9A, #9B, #9C, #9D, #9E & #9F of this Project #1 Requirement Document located in this SECTION 5F in pages to follow .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

27 ❖ Requirement #1m – [SPRINT #4 ONLY] For the CONTENT of SUB- SECTION-HEADERS 17 READ the following instructions: 1. SUB-SECTION HEADERS 16 is the conclusion. 2. See the instructions below to populate the remaining sections: 17) Conclusion: 1. This sub-section is a conclusion of the entire project #1 which includes: a) Purpose of project. b) What was done? c) Key points of the project. d) Outcome e) Etc. 2. Go Do #1 – Populate/Finalize the conclusion paragraph(s) . ❖ Requirement #1n – [SPRINT #4] SPRINT #4 DELIVERABLE REQUIREMENTS – What & How to Submit in this SPRINT: 1. Is important that you submit your SPRINT #4 based on the requirements listed in Requirements #11e of SECTION 6 – PROJECT 1 DELIVERABLES . 2. Follow the instructions in Requirements #11e exactly as indicated.  Requirement #1 – END OF SPRINT #4  STOP HERE if Executing SPRINT #4

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

28 Requirement #2 (2 POINTS) – ( Phase 2 – Analysis ) – List the Business Requirements & Application Technical and Development Requirements for PROJECT 1 in the Design & Implementation Document ❑ In this requirement, you need to: Database Design Deliverable #1a – The Business Requirements ❖ Requirement #2a – START by READING the instructions in Requirement #1e Section 5 Sub-Section-Header 4 for an overview of the Application Business Requirements 1. Go Do #1: Read Requirement #1e Section 5 Sub-Section-Header 4 & 5 which describes the Application Business requirements & Application Development Technical Requirements . These two sections provide an overview of this REQUIREMENT #2 and descriptions that can help you create the sub-section-header paragraphs required for this REQUIREMENT #2 . ❖ Requirement #2b – COPY/PASTE the APPLICATION BUSINESS REQUIREMENTS OF THIS DOCUMENT to the required Sub-Section in the Design & Implementation Project Document Created in Requirement #1 1. The Application Business Requirements listed in this PROJECT 1 Requirements document must be copied to your Design & Implementation Project Document created in requirement #1 , to SUB-SECTION-HEADER 4 Application Business Requirements . 2. Go Do #1: 1) Go to the ZIP FOLDER PACKAGE included with these requirements and open the Business & Technical Requirements Document . 2) COPY/PASTE the Application Business Requirements only to SUB-SECTION-HEADER 4 – Application Business Requirements of your Design & Implementation Project Document . 3. Now your Design & Implementation Project Document will contain the Application Business Requirements .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

29 ❖ Requirement #2c – BUSINESS REQUIREMENTS FORMAT & PRESENTATION 1. Go Do #1 – Execute Requirement #1b and make sure you CREATE A PARAGRAPH DESCRIBING THIS SUB-SECTION AND WHAT IS IN IT/BEING DELIVERED . 2. Go Do #2 – Execute Requirement #1c and make sure the paragraph is CUSTOMER READY! REMEMBER THAT YOU ARE BEING GRADED ON THE FORMAT AND QUALITY OF YOUR DOCUMENT AND THE ABILITY OF THE READER (CUSTOMER) TO UNDERSTAND WHAT WAS DONE AND HOW . Database Design Deliverable #1b – The Application Development Technical Requirements ❑ In this requirement, you also need to execute: ❖ Requirement #2d – COPY/PASTE the APPLICATION DEVELOPMENT TECHNICAL REQUIREMENTS OF THIS DOCUMENT to the required Sub-Section in the Design & Implementation Project Document Created in Requirement #1 1. The Application Development Technical Requirements listed in this PROJECT 1 Requirements document must be copied to your Design & Implementation Project Document created in requirement #1 , to SUB-SECTION-HEADER 5 – Application Development Technical Requirements . 2. Go Do #1: 1) Go to the ZIP FOLDER PACKAGE included with these requirements and open the Business & Technical Requirements Document . 2) COPY/PASTE the Application Development Technical Requirements only to SUB- SECTION-HEADER 5 – Application Development & Technical Requirements of your Design & Implementation Project Document . 3. Now your Design & Implementation Project Document will contain the Application Development Technical Requirements . ❖ Requirement #2e – APPLICATION DEVELOPMENT & TECHNICAL REQUIREMENTS FORMAT & PRESENTATION 1. Go Do #1 – Execute Requirement #1b and make sure you CREATE A PARAGRAPH DESCRIBING THIS SUB-SECTION AND WHAT IS IN IT/BEING DELIVERED . 2. Go Do #2 – Execute Requirement #1c and make sure the paragraph is CUSTOMER READY! REMEMBER THAT YOU ARE BEING GRADED ON THE FORMAT AND QUALITY OF YOUR DOCUMENT AND THE ABILITY OF THE READER (CUSTOMER) TO UNDERSTAND WHAT WAS DONE AND HOW .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

30 Section 5b – Execute Project Management Methodology Analysis Phase SPRINT #1 Requirements #3 ❑ In this section, the Database Analyst/Architect will execute the Analysis phase of the project and output the requires deliverable from this phase which is the ER/EER Conceptual Model Diagram as indicated in this requirement. ❑ Overview of objectives, activities and deliverables for this phase are shown below: ANALYSIS PHASE – Detailed description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

31 Requirement #3 (2 POINTS) – ( Phase 2 – Analysis ) – List the resultant EER Conceptual Model DIAGRAM Derived from the Business Requirements for the Auto Rental Database Application Database Design Deliverable #2 – The EER Conceptual Model Diagram ❑ DIAGRAM #1 – A Database Analyst/Architect was hired by your sponsor Mr. Rodriguez, who derived the EER Conceptual Model for the AUTO MANAGEMENT SYSTEM , based on the Application Business Requirements as part of the Analysis Phase deliverables . ❑ This EER Conceptual Model Diagram is the foundation of the Database Design for the DBMS Auto Rental Management System Application . Its goal is to take the entities and relationships identified in the Application Business Requirements and connect them together to build a DIAGRAM or high-level picture of how the Application key Business data relate to each other. ❑ This diagram needs to be included in your Design & Implementation Project Document . ▪ THIS DIAGRAM IS PROVIDED FOR YOU IN THE ZIP FOLDER PACKAGE SO YOU CAN COPY DIRECTLY TO YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT ❑ In this requirement, you need to: ❖ Requirement #3a – START by READING the instructions in Requirement #1f Section 2 Sub-Section-Header 10 for an overview of the Database Design Deliverable #2 – ER/EER Conceptual Model Diagram Requirements 2. Go Do #1: Read Requirement #1f Section 2 Sub-Section-Header 10 which describes the Database Design Deliverable #2 – ER/EER Conceptual Model Diagram . This section provides an overview of this REQUIREMENT #3 and descriptions that can help you create the sub-section-header paragraphs for this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

❖ Requirement #3b – COPY/PASTE the EER CONCEPTUAL MODEL DIAGRAM OF THIS DOCUMENT to the required Sub-Section in the Design & Implementation Project Document Created in Requirement #1 1. The EER Conceptual Model image listed in the NEXT PAGES of this PROJECT 1 Requirements document must be COPIED to your Design & Implementation Project Document created in requirement #1 , to SUB-SECTION-HEADER 9: Database Design Deliverable #1 – ER/EER Conceptual Model Diagram . 2. Go Do #1: 1) Go to the ZIP FOLDER PACKAGE included with these requirements and COPY the Car Rental CHEN EER ASSOCIATIVE ENTITY DIAGRAM image . 2) PASTE the Car Rental CHEN EER ASSOCIATIVE ENTITY DIAGRAM image to SUB- SECTION-HEADER 9: Database Design Deliverable #1 – ER/EER Conceptual Model Diagram of your Design & Implementation Project Document . 3. Now your Design & Implementation Project Document will contain the ER/EER Conceptual Model Diagram image in the correct section. ❖ Requirement #3c – EER CONCEPTUAL MODEL DIAGRAM FORMAT & PRESENTATION REQUIREMENTS 1. Go Do #1 – Execute Requirement #1b and make sure you CREATE A PARAGRAPH DESCRIBING THIS SUB-SECTION AND WHAT IS IN IT/BEING DELIVERED . 2. Go Do #2 – Execute Requirement #1c and make sure the paragraph is CUSTOMER READY! REMEMBER THAT YOU ARE BEING GRADED ON THE FORMAT AND QUALITY OF YOUR DOCUMENT AND THE ABILITY OF THE READER (CUSTOMER) TO UNDERSTAND WHAT WAS DONE AND HOW . NOTE YOU ARE NOT CREATING THIS DIAGRAM YOURSELF, THAT WAS ALREADY DONE FOR YOU, JUST SIMPLY COPY THE DIAGRAM TO THE DESIGN & IMPLEMENTATION DOCUMENT! NEVERTHELESS, TO LEARN HOW TO CREATE ER & EER CONCEPTUAL DIAGRAM FROM THE BUSINESS REQUIREMENTS GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ CST4708 Lecture 6B - Data Modeling. ER modeling ‐ CST3504 Lecture 2A, 2B, & 2C - Data Modeling. ER modeling HWS & examples shown in lecture 2C ‐ CST3504 Lecture 3A & 3B – Enhanced ER Model. EER Modeling HWs & examples shown in Lecture 3B ▪ Book: CST3504 Course Textbook

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

EER Conceptual Model using Associative Entities derived from Business Requirements ❑ Below is the Database Analyst/Architect rendition of the EER Model of the Business Requirements for Project 1, with standard CHEN notation and using Associative entities. Copy this diagram to your project document. I provided the JPG image file in the ZIP PACKAGE for you to use. ❖ THE JPG IMAGE FILE FOR THIS DIAGRAM IS PROVIDED TO YOU IN THE ZIP FOLDER PACKAGE . SIMPLY COPY/PASTE TO YOUR DOCUMENT.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Section 5c – Execute Project Management Methodology Design Phase SPRINT #1 Requirements #4 ❑ We start the design phase by dividing the design phase into three parts: Part 1 the Normalized Logical Model , Part 2 the Data Dictionary & Part 3 the Physical Schame Diagram Design . ❑ In this section we focus on Part 1 is the Normalized Logical Model . The Database Analyst/Architect will execute this first part of the Design phase and output the requires deliverable from this phase as indicated in this requirement. ❑ Overview of objectives, activities and deliverables for this phase are shown below: DESIGN PHASE Part 1 – Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

35 Requirement #4 (2 POINTS) – ( Phase 2 – Design ) – List the Normalized Logical Model DIAGRAMS for the Auto Rental Management System Application Database Design Deliverable #3 – The Normalized Logical Model Diagram ❑ The Database Analyst/Architect hired by your sponsor Mr. Rodriguez, Also derived & normalized the Normalized Logical Model Diagram for the AUTO MANAGEMENT SYSTEM , from the EER Conceptual Model Diagram as part of one of the Design Phase deliverables . ❑ This Normalized Logical Model Diagram is the 2 nd foundation of the Database Design for the DBMS Auto Rental Management System Application . Its goal is to take the EER Conceptual Model Diagram , which focuses on the entities and relationships of the required business data to the actual database TABLES and their RELATIONSHIPS that will be IMPLEMENTED in a database. In other words, it shows how the TABLES and RELATIONSHIPS will look like in a Database (DBMS) when you implement it . This is known as the SCHEMA ! ❑ We will break up the into 3 diagrams for the project, based on our deployment strategy and methodology: 1) DIAGRAM #1 – The complete Normalized Logical Model Diagram for the AUTO MANAGEMENT SYSTEM deri derived from the EER Conceptual Model Diagram . 2) DIAGRAM #2 – The limited PILOT Normalized Logical Model Diagram that includes only 13 tables only from the full normalized model . This will be the first production deployment rollout to test the application on a limited number of users in different locations to flush out any unforeseen errors in the AUTO MANAGEMENT SYSTEM . 3) DIAGRAM #3 – A limited PROOF-OF-CONCEPT PROTOTYPE portion of Normalized Logical Model Diagram that includes only 2 tables only from the full normalized model. This will be used for a PROTOTYPE version of the AUTO MANAGEMENT SYSTEM to prove out the concept. ❑ All three of these diagrams need to be included in your Design & Implementation Project Document . ▪ THESE DIAGRAMS ARE PROVIDED FOR YOU IN THE ZIP FOLDER PACKAGE SO YOU CAN COPY THEM DIRECTLY TO YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

36 ❖ Requirement #4a – START by READING the instructions in Requirement #1f Section 2 Sub-Section-Header 11 for an overview of the Database Design Deliverable #3 – Normalized Logical Model Diagram, Limited Pilot Normalized Logical Model Diagram Requirements & Proof-of-Concept Diagram Requirements 1. Go Do #1: Read Requirement #1f Section 2 Sub-Section-Header 11 which describes the Database Design Deliverable #3 – Normalized Logical Model Diagram . This section provides an overview of this REQUIREMENT #4 and descriptions that can help you create the sub-section-header paragraphs for this requirement. ❖ Requirement #4b – COPY/PASTE the FULL NORMALIZED LOGICAL MODEL DIAGRAM ( 33 Logical Tables) to the required Sub- Section in your Design & Implementation Project Document Created in Requirement #1 1. The LIMITED PILOT Normalized Logical Model Diagram image listed in the NEXT PAGE of this PROJECT 1 Requirements document must be copied to your Design & Implementation Project Document created in requirement #1 , to SUB-SECTION-HEADER 11: Database Design Deliverable #2 – Normalized Logical Model Diagram . 2. Go Do #1: 1) Go to the ZIP PACKAGE included with these requirements and COPY the Car Rental LIMITED PILOT Normalized Logical Model DIAGRAM image . 2) PASTE the Car Rental LIMITED PILOT Normalized Logical Model DIAGRAM image to SUB-SECTION-HEADER 10: Database Design Deliverable #2 – Normalized Logical Model Diagram of your Design & Implementation Project Document . 3. Now your Design & Implementation Project Document will contain the Car Rental LIMITED PILOT Normalized Logical Model DIAGRAM image in the correct section including the describing paragraphs before the image as per Requirement #1b .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Production Normalized Logical Model ❑ Below is the architect’s rendition of the Normalized Logical Model based on EER diagram in previous section. Note there are 33 logical tables : ❖ PLEASE NOTE THAT AT THE END OF THIS DOCUMENT, THERE IS AN APPENDIX SECTION WHERE I ALSO LIST THE NON-NORMALIZED LOGICAL MODEL THAT WAS THE FOUNDATION OF THE NORMALIZED MODEL ABOVE. ❖ I AM LISTING IT FOR TEACHING PURPOSE SO YOU CAN SEE THE TRANSITION TO NORMALIZATION.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

❖ Requirement #4c – NORMALIZED LOGICAL MODEL DIAGRAM FORMAT & PRESENTATION REQUIREMENTS 1. Go Do #1 – Execute Requirement #1b and make sure you CREATE A PARAGRAPH DESCRIBING THIS SUB-SECTION AND WHAT IS IN IT/BEING DELIVERED . 2. Go Do #2 – Execute Requirement #1c and make sure the paragraph is CUSTOMER READY! REMEMBER THAT YOU ARE BEING GRADED ON THE FORMAT AND QUALITY OF YOUR DOCUMENT AND THE ABILITY OF THE READER (CUSTOMER) TO UNDERSTAND WHAT WAS DONE AND HOW . ❖ Requirement #4d – COPY/PASTE the PROOF-OF-CONCEPT NORMALIZED LOGICAL MODEL DIAGRAM OF THIS DOCUMENT to the required Sub-Section in the Design & Implementation Project Document Created in Requirement #1 1. The PROOF-OF-CONCEPT Normalized Logical Model Diagram image listed in the NEXT PAGE of this PROJECT 1 Requirements document must also be copied to your Design & Implementation Project Document to SUB-SECTION-HEADER 11: Database Design Deliverable #3 – Normalized Logical Model Diagram , after the listing of the PILOT Normalized Logical Model DIAGRAM image and it’s describing paragraph. 2. Go Do #1: 1) Go to the ZIP FOLDER PACKAGE included with these requirements and COPY the Car Rental PROOF-OF-CONCEPT Normalized Logical Model DIAGRAM image . 2) PASTE the Car Rental PROOF-OF-CONCEPT Normalized Logical Model DIAGRAM image to SUB-SECTION-HEADER 11: Database Design Deliverable #3 – Normalized Logical Model Diagram of your Design & Implementation Project Document . 3. Now your Design & Implementation Project Document will contain the Normalized Logical Model Diagram image , the Car Rental LIMITED PILOT Normalized Logical Model DIAGRAM image and the PROOF-OF-CONCEPT Normalized Logical Model DIAGRAM image in the correct section including the describing paragraphs before the image as per Requirement #1b ..

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Normalized Logical Model Limited Pilot ❑ Below is the LIMITED PILOT Normalized Logical Model that will be deploy to a limited number of users throughout the organization as a final production test. This diagram only contains the 13 logical tables in scope of the PILOT : ❖ PLEASE NOTE THAT AT THE END OF THIS DOCUMENT, THERE IS AN APPENDIX SECTION WHERE I ALSO LIST THE NON-NORMALIZED LOGICAL MODEL THAT WAS THE FOUNDATION OF THE NORMALIZED MODEL ABOVE. ❖ I AM LISTING IT FOR TEACHING PURPOSE SO YOU CAN SEE THE TRANSITION TO NORMALIZATION.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

❖ Requirement #4e – COPY/PASTE the LIMITED PILOT NORMALIZED LOGICAL MODEL DIAGRAM OF THIS DOCUMENT to the required Sub-Section in the Design & Implementation Project Document Created in Requirement #1 4. The Limited Pilot Normalized Logical Model Diagram image listed in the NEXT PAGE of this PROJECT 1 Requirements document must also be copied to your Design & Implementation Project Document to SUB-SECTION-HEADER 11: Database Design Deliverable #3 – Normalized Logical Model Diagram , after the listing of the full Normalized Logical Model Diagram . 5. Go Do #1: 3) Go to the ZIP FOLDER PACKAGE included with these requirements and COPY the Car Rental Normalized Logical Model PILOT DEPLOYMENT DIAGRAM image . 4) PASTE the Car Rental Normalized Logical Model PILOT DEPLOYMENT DIAGRAM image to SUB-SECTION-HEADER 10: Database Design Deliverable #3 – Normalized Logical Model Diagram of your Design & Implementation Project Document , AFTER the listing of the full Normalized Logical Model Diagram . 6. Now your Design & Implementation Project Document will contain the Normalized Logical Model Diagram image and the Limited Pilot Normalized Logical Model Diagram image in the correct section including the describing paragraphs before the image as per Requirement #1b ..

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Normalized Logical Model PROOF-OF-CONCEPT PROTOTYTYPE ❑ Below is the PROOF-OF-CONCEPT (POC) Normalized Logical Model that will be used to create a PROTOTYPE of the application to demo to the business. This diagram only contains the 4 logical tables in scope of the POC : ❖ PLEASE NOTE THAT AT THE END OF THIS DOCUMENT, THERE IS AN APPENDIX SECTION WHERE I ALSO LIST THE NON-NORMALIZED LOGICAL MODEL THAT WAS THE FOUNDATION OF THE NORMALIZED MODEL ABOVE. ❖ I AM LISTING IT FOR TEACHING PURPOSE SO YOU CAN SEE THE TRANSITION TO NORMALIZATION.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

❖ Requirement #4f – PROOF-OF-CONCEPT NORMALIZED LOGICAL MODEL DIAGRAM FORMAT & PRESENTATION REQUIREMENTS 3. Go Do #1 – Execute Requirement #1b and make sure you CREATE A PARAGRAPH DESCRIBING THIS SUB-SECTION AND WHAT IS IN IT/BEING DELIVERED . 4. Go Do #2 – Execute Requirement #1c and make sure the paragraph is CUSTOMER READY! REMEMBER THAT YOU ARE BEING GRADED ON THE FORMAT AND QUALITY OF YOUR DOCUMENT AND THE ABILITY OF THE READER (CUSTOMER) TO UNDERSTAND WHAT WAS DONE AND HOW . NOTE YOU ARE NOT CREATING THE DIAGRAMS LISTED IN THE PREVIOUS REQUIREMENTS YOURSELF, THAT WAS ALREADY DONE FOR YOU, JUST SIMPLY COPY THE DIAGRAM TO THE DESIGN & IMPLEMENTATION DOCUMENT! NEVERTHELESS, TO LEARN HOW TO CREATE ER & EER CONCEPTUAL DIAGRAM FROM THE BUSINESS REQUIREMENTS GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lecture: ‐ CST4708 Lecture 6B – Database Design ‐ CST3504 Lecture 4 - Logical DB Design (see conversion rules) ▪ Book: CST3504 Course Textbook

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

43 Section 5d – Execute Project Management Methodology Design Phase SPRINT #2 Requirements #5 & #6 ❑ In this section we continue the design phase by executing Part 2 the Data Dictionary & Part 3 the Physical Schema Diagram Design . ❑ The Database Developer (YOU) will now execute the second & third parts of the Design phase and output the requirements deliverable from this phase as indicated in this requirement. ❑ Overview of objectives, activities and deliverables for this phase are shown below: DESIGN PHASE Part 2 & 3 – Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

44 Requirement #5 (20 POINTS) – (DESIGN PHASE) – Create a Data Dictionary/METADATA Tabular Listing for all Attributes of either the LIMITED PILOT Normalized Logical Model for CST3604 Class Targeting ORACLE SERVER DBMS or the PROOF-OF-CONCEPT Normalized Logical Model for CST4708 Class Targeting MICROSOFT SQL SERVER DBMS of the Auto Rental Database Application Database Design Deliverable #4 – The Data Dictionary Tabular Listing ❑ Create a Data Dictionary by SELECTING THE BEST DATA TYPES FOR ALL ATTRIBUTES/COLUMNS OF THE LIMITED PILOT Normalized Logical Model for CST3604 and PROOF-OF-CONCEPT Normalized Logical Model for CST4708 of Requirement #4 as follows: ❖ Requirement #5a – START by READING the instructions in Requirement #1h Section 3 Sub-Section-Header 12 for an overview of the Database Design Deliverable #4 – Physical Model Data Dictionary Requirements 1. Requirement #5a GO DO #1: Read Requirement #1h Section 2 Sub-Section-Header 12 which describes the Database Design Deliverable #4 – Physical Model Data Dictionary . This section provides an overview of this REQUIREMENT #5 and descriptions that can help you create the sub- section-header paragraphs for this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

45 2. Below are two examples of a Physical Model Data Dictionary tables of a Customer Dictionary Table using Microsoft SQL Server DBMS & Oracle Server DBMS Data Types to give you an idea of the goals of this requirement: 1) CST4708 – Customer Dictionary Table using MS SQL Server DBMS Data Types : 2) CST3604 – Customer Dictionary Table using Oracle Server DBMS Data Types :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

46 ❖ Requirement #5b – CST3604 COPY/PASTE 13 out of 33 EMPTY DATA DICTIONARY TABULAR LISTINGS & CST4708 CLASS COPY/PASTE 4 out of 33 EMPTY DATA DICTIONARY TABULAR LISTINGS FROM THE DATA DICTIONARY TEMPLATE DOCUMENT LOCATED IN THE ZIP PACKAGE TO YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT : 1. Requirement #5b GO DO #1 – As part of the resource ZIP FOLDER PACKAGE , I provided you with a Data Dictionary Template Document which contains a total of 33 Data Dictionary tabular listings that include the table headers and attributes from all the tables in the Normalized Logical Model for you to leverage and create your Data Dictionary tabular listings . 2. THERE ARE 33 DATABASE TABLES IN THE FULL NORMALIZED LOGICAL MODEL, BUT THE NUMBER OF DICTIONARY TABLES YOU WILL NEED TO IMPLEMENT WILL DEPEND ON WHETHER YOU ARE CST3604 OR CST4708 TEAMS AS SHOWN BELOW:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

47 FOR CST3604 CLASS ONLY 3. For CST3604 Team, ONLY 13 DICTIONARY TABLES FOR THE LIMITED PILOT NORMALIZED LOGICAL MODEL ARE IN SCOPE OF CST3604 CLASS . 4. Therefore, for Requirement #5b GO DO #1 , CST3604 Class COPY/PASTE from the CST3604 Data Dictionary Template Document THE 13 DATA DICTIONARY TABLES OF THE LIMITED PILOT NORMALIZED LOGICAL MODEL TO YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT in Sub-Section 11 Database Design Deliverable #4 – Physical Model Data Dictionary as indicated in Requirement #1h . The remaining 20 tables are for future implementation of the other features if you wish to continue learning with this project . 5. Below is a SNAPSHOT of only 2 out of 13 Data Dictionary tabular listings templates that you will copy from the ZIP FOLDER PACKAGE folder look like: CST3604 – Oracle Server: … Other remaining 11 Dictionary Templates. 6. Once you copy the 13 TEMPLATE DICTIONARY TABLES to your Project Design & Implementation Document , you are now ready to DESIGN & CREATE the DATA TYPE & METADATA for each of the 13 TEMPLATE DICTIONARY TABLES . You will need to follow Requirement #5c in the next pages ahead.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

48 FOR CST4708 CLASS ONLY 7. For CST4708 Team, ONLY 4 DICTIONARY TABLES FOR THE PROOF-OF-CONCEPT NORMALIZED LOGICAL MODEL ARE IN SCOPE OF CST4708 CLASS . 8. Therefore, for Requirement #5b GO DO #1 , CST4708 Class COPY/PASTE from the CST4708 Data Dictionary Template Document THE 4 DATA DICTIONARY TABLES OF THE PROOF-OF-CONCEPT NORMALIZED LOGICAL MODEL TO YOUR PROJECT DESIGN & IMPLEMENTATION DOCUMENT in Sub-Section 11 Database Design Deliverable #4 – Physical Model Data Dictionary as indicated in Requirement #1h . The remaining 29 tables are for future implementation of the other features if you wish to continue learning with this project . 9. Below is a SNAPSHOT of only 2 out of 13 Data Dictionary tabular listings templates that you will copy from the ZIP FOLDER PACKAGE folder look like: CST4708 – MS SQL Server: … Other remaining 2 Dictionary Templates. 10. Once you copy the 4 TEMPLATE DICTIONARY TABLES to your Project Design & Implementation Document , you are now ready to DESIGN & CREATE the DATA TYPE & METADATA for each of the 4 TEMPLATE DICTIONARY TABLES . You will need to follow Requirement #5c in the next pages ahead.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

49 FOR BOTH CST3604 & CST4708 CLASSES 11. Below are TWO examples of a Data Dictionary tabular listings for another database design project that contains only 3 tables , to show you examples of what you are being asked to do 12. The FIRST example is for CST4708 class, where this database design contains 3 fully populated Dictionary Tables with DATA TYPE & METADATA targeting Microsoft SQL Server DBMS Data Types . 13. The SECOND example is for CST3604 database design is the same design as the FIRST with 3 fully populated Dictionary Tables with DATA TYPE & METADATA BUT this time targeting Oracle Server DBNS Data Types . Warning! – The examples below are from another application database design, NOT THE TABLES FOR THIS PROJECT!  DO NOT COPY THESE TABLES TO YOUR PROJECT DOCUMENT, THEY ARE NOT PART OF YOUR PROJECT!  NEVERTHELESS, YOU CAN LEVERAGE SOME OF THE DATA TYPE DECISIONS IN THESE EXAMPLES BUT MODIFY AS NEEDED TO MATCH THIS PROJECT’S REQUIREMENTS.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

50 1) CST4708 CLASS ONLY – Below is an example of a Data Dictionary tabular listings for a small business database design that contains only 3 tables fully populated Dictionary Tables with DATA TYPE & METADATA targeting Microsoft SQL Server DBMS Data Types . TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ CST4708_ Lecture 6B – Database Design & CST3504 Lecture 5A - Physical Design ‐ Also help can be found in the requirements listed in this Requirement #5

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

51 2) CST3604 CLASS ONLY – Below is an example of a Data Dictionary tabular listings for a small business database design that contains only 3 tables fully populated Dictionary Tables with DATA TYPE & METADATA targeting Oracle Server DBMS Data Types . TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ CST3504 Lecture 5A - Physical Design Intro ‐ Also help can be found in the requirements listed in this Requirement #5

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

52 FOR BOTH CST3604 & CST4708 CLASSES ❖ Requirement #5c – REVIEW THE THEORY WITH PROF. RODRIGUEZ ON HOW TO CREATE A DATA DICTIONARY TABLE AND SELECTING DATA TYPE & METADATA FOR EVERY TABLE COLUMN IN THE NORMALIZED LOGICAL MODEL. SEE APPENDIX C OF THIS DOCUMENT FOR THE THEORY ON HOW TO DESIGN THE DATA TYPES AND APPENDIX D & APPENDIX E FOR A LISTING OF MS SQL SERVER & ORACLE SERVER DATATYPES.  Designing the DATA TYPE for Database Table COLUMNS is a CREATIVE process based on Theoretical GUIDELINES WHICH ARE LISTED IN REQUIREMENT #5 & APPENDIX C of this document. In addition, more detailed theory can be found in the following 2 lectures: o CST4708 CLASS – CST4708_LECTURE 6B & CST3504_LECTURE 5A o CST3604 CLASS – CST3504_LECTURE 5A.  Prof. Rodriguez will review the theory contained in these lectures in class and SUMARIZING THE THEORY in this section of REQUIREMENT #5 & APPENDIX C. With the class summary, you should NOT need to read these lectures, unless you need to see more examples etc. 1. PROF. RODRIGUEZ will deliver a Summary of the theory and provide guidance in this Requirement #5 . More important, this requirement #5 has a section that will take you STEP-BY-STEP and tell you what to do and provide examples and recommendations for data types in your project . This means you will have answers to some of the columns in your Dictionary . SEE Requirement #5d-4 for the details .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

53 2. Note that this process of designing the DATA TYPE & METADATA for every column of a table requires a combination of the following resources and process:  GUIDANCE ON PROCESS – the process of designing and deriving the data types for the columns of the tables in the database is NOT easy since is a creative process that can includes a combination of the following: 1) The Normalized Logical Model of Requirement #4 . 2) The theory in APPENDIX C . & the theory provided in this Requirement #5 . 3) Data Type clues and examples provided in the Business Requirements . 4) Data Type examples provided in the theory review of this Requirement #5 . 5) IMPORTANT! Data Type examples provided in Requirement #5d-4.1 to Requirement #5d- 4.25 of this Requirement #5 . 6) Research the business you are designing the Data Types to help you make the correct decisions. 7) Your decision MAKES BUSINESS SENSE . When deciding on a Data Type make sure the decision MAKES SENSE TO THE TYPE OF BUSINESS . 8) You will need to Think & be Creative . 9) Experience from previous work and projects.  This means you need a combination of the following: 1) The Normalized Logical Model of Requirement #4 & the EER Conceptual Model of Requirement #3 – to determine the columns and constraints for every column of every table. Note that this has already been given to you in the Data Dictionary Template document. 2) Theory & concepts – To do this job, normally you will need a deep understanding of the theory (guidance from books, courses, white papers, videos etc.). Nevertheless, in APPENDIX C . and in this Requirement #5c I will review the theory with you and in addition, integrate the theory into FLOWCHARTS that you can follow to implement you DATA DICTIONARY TABLES to assist you . 3) Business Requirements – Deep analysis & understanding of the business requirements since the Business Requirements contain Data Type clues and examples that will assist you in determining the correct data types in many instances. 4) Data Type examples – provided in APPENDIX C and the theory of this Requirement #5 – All over APPENDIX C and Requirement #5 there are many examples that you can leverage since I used actual columns from your project. For example, the scenario with 3 Data Dictionary Tables ( CUSTOMER, PRODUCT & PURCHASE DICTIONARY TABLES ) in previous pages provide many examples you can leverage and use like First & Last Name, address information etc., for the Customer table in the examples can be leveraged as is to populate your customer dictionary table. 5) IMPORTANT! EXECUTING Requirement #5d-4.1 to Requirement #5d-4.25 of this Requirement #5 is the most important part of this Requirement #5 : ➢ In this section, there is a table that contains a LIST OF REQUIREMENTS labeled Requirement #5d- 4.1 to Requirement #5c-4.25 which are specific requirements that YOU NEED TO FOLLOW & IMPLEMENT FOR THE COLUMNS INDICATES IN YOUR DATA DICTIONARY TABLES. ➢ YOU MUST FOLLOW THESE REQUIREMENTS SINCE I WILL BE GRADING YOUR DATA DICTIONARY BASED ON THESE REQUIREMENTS! ➢ DO NOT IGNORE THIS TABLE!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

54 6) Research on the Type of Business you are designing – you need to research the type of business and how they operate etc., to be better armed to make certain Data Type decisions that affect the business. If you need to make such decisions, you need to know the business. 7) Data Type decision Business Sense – When you make a data type decision, ask yourself if this makes business sense for this type of business. Think about the type of business you are designing for. 8) Creativity – you need to think. Engage the creative side of your mind. This is a thinking process and the reason this may be challenging for some of you. 9) Experience – experience is always a positive factor. After going through the process a few times, you get better and able to make better Data Type decisions based on challenges and respective resolutions from experience.  In my opinion, one of the MOST IMPORTANT and most difficult decisions you need to make in this project and Database Design is deciding on the Data type & Constraints of each column in the Logical Model: - A wrong decision here can have a significant impact on the security and data integrity of the database. - A wrong decision here will cascade to development and implementation activities that will be done wrong, therefore when a Data Type mistake is identified in the development and implementation phase, the process needs to go back and re-do the Data Type process for those erroneous decisions. - You must get the Data Type decisions right or the best choice selection possible. - Keep in mind that there are limitations of the DBMS Data Type, and you will need to decide within those limitations. 3. You will need to LEVERAGE all these 9 CRITERIAS to design & create each of the DATA TYPE & METADATA for every column of each table. The point is that YOU WILL NOW HAVE TO THINK & Be Creative and APPLY THE THEORY! I will help guide you!  IMPORTANT - This DATA DICTIONARY deliverable of the design process is extremely important since choosing the wrong data type can affect performance , security , wasted storage space ($$$$) & High Cost ($$$$) ! These are the reasons why it is important and requires THINKING.  Wrong decisions here can get you fired in some scenarios! 4. Requirement #5c GO DO #1 – GO TO APPENDIX C and follow along with Professor Rodriguez’s as he reviews the SUMMARY of the THEORY on how to determine the DBMS Data Type & Constraint for all columns of a table.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

55 ❖ Requirement #5d (GO DO #1 through GO DO #25) – FOR ALL 13 DICTIONARY TABLES OF CST3604 PILOT LOGICAL MODEL DESIGN & FOR ALL 4 DICTIONARY TABLES OF CST4708 PROOF- OF-CONCEPT LOGICAL MODEL, ENTER THE DATA TYPE FOR EACH OF THE ATTRIBUTES/COLUMNS OF EACH DICTIONARY TABLE TARGETING MS SQL SERVER for CST4708 & ORACLE SERVER for CST3604 DATA TYPES : FOR CST3604 CLASS ONLY 1. Requirement #5d GO DO#1 through GO DO #25 – FOR EACH of the 13 empty DICTIONARY TABLES , DESIGN & ADD the DBMS DATA TYPE, CONSTRAINT & METADATA INFORMATION to COMPLETE each of the 13 DICTIONARY TABLES using ORACLE SERVER Database Management System (DBMS) DATA TYPES . See APPENDIX E for a listing of ORACLE SERVER DBMS DATA TYPES . 2. APPENDIX C of this document contains the theory that Professor Rodriguez will cover in class with 5 DESIGN GUIDELINES & SUMMARY OF STEPS TO SELECTING DATA TYPES & CONSTRAINTS . FOR CST4708 CLASS ONLY 1. Requirement #5d GO DO#1 through GO DO #25 – FOR EACH of the 4 empty DICTIONARY TABLES , DESIGN & ADD the DBMS DATA TYPE, CONSTRAINT & METADATA INFORMATION to COMPLETE each of the 4 DICTIONARY TABLES using MS SQL SERVER Database Management System (DBMS) DATA TYPES . See APPENDIX D of this document for a listing of MS SQL SERVER DBMS DATA TYPES . 2. APPENDIX C of this document contains the theory that Professor Rodriguez will cover in class with 5 DESIGN GUIDELINES & SUMMARY OF STEPS TO SELECTING DATA TYPES & CONSTRAINTS .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

56 FOR BOTH CST3604 & CST4708 CLASSES 3. SUPER IMPORTANT In addition to the 5 DESIGN GUIDELINES DATA TYPE RULES in APPENDIX C, you MUST EXECUTE the following DATA TYPES REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.25 which will be described below:  REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.25 are LISTED in a table in pages to follow.  THE REQUIREMENTS IN THIS TABLE BELOW MUST BE EXECUTED!  THESE REQUIREMENTS CONTAIN INSTRUCTIONS TO YOU INDICATING DETAILED REQUIREMENTS FOR CERTAIN TABLE COLUMNS AND DATA TYPE TO CHOOSE.  THESE ARE THE MOST IMPORTANT REQUIREMENTS IN SPRINT #2! DO NOT SKIP THESE REQUIREMENTS  IN THESE REQUIREMENTS, I AM TELLING YOU WHAT DATA TYPE TO USE FOR SPECIFIC ATTRIBUTES/COLUMNS AND FOR CERTAIN CATEGORIES OF ATTRIBUTES/COLUMNS in the database.  THESE ARE VERY IMPORTANT REQUIREMENTS SINCE ABOUT 85+% OF YOUR GRADE WILL BE DETERMINED BY THESE REQUIREMENTS!  THESE REQUIREMENTS ALSO CONTAIN ACTUAL EXAMPLES AND ANSWERS WHICH ARE PART OF THE PROJECT. I AM ACTUALLY GIVING YOU ANSWERS SO DON’T IGNORE THIS TABLE!  WARNING! YOUR GRADE FOR THIS REQUIREMENT #5 IS PRIMARILY BASED ON THE REQUIREMENTS 5dc-4.1 to REQUIREMENTS 5d-4.25 . OVERLOOK, SKIP OR IGNORE THESE REQUIREMENTS AND YOU WILL REGREAT IT!  WARNING! NOT EXECUTING THIS TABLE WILL DRASTICALLY REDUCE YOUR OVERALL GRADE FOR THIS PROJECT!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

57 4. SUPER IMPORTANT REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.25 are divided into the following sections: 1) Execute Requirement #5d-4.1 to determine the DBMSDataType & Constraints for the PRIMARY KEY columns . 2) Execute Requirement #5d-4.2 through Requirement #5d-4.5 to determine the DBMSDataType & Constraints for the FOREING KEY non-key columns . 3) Execute Requirement #5d-4.6 through Requirement #5d-4.25 to determine the DBMSDataType & Constraints for all the remaining NON-KEY columns .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

58 5. The FLOWCHART below, walks you through the MAIN STEPS to deriving the DBMSDataType & Constraints for Requirement #5 and most important, the DATA TYPES in REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.25 : Main Flow Chart for Determining DBMSDataType & Constraint for Requirements 5d-4.1 to Requirements 5d-4.25 Main Process Flow Chart:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

59 6. Requirement #5d-4.1 GO DO#1 – APPENDIX C, DESIGN GUIDELINE DATA TYPE RULE #3 – states “START & FOCUS ON DESIGNING THE DBMSDATATYPE & CONSTRATINS FOR THE PRIMARY KEY COLUMN OF A DICTIONARY TABLE ” . The Primary Key column DBMSDataType & Constraints is the most IMPORTANT and challenging to derive. This column owns the table. Get this column wrong and serious flaws in your implementation will occur.  The FLOWCHART below walks you through the STEPS to deriving the DBMSDataType & Constraints for ALL the PRIMARY KEYS in REQUIREMENTS 5d-4.1 : Detailed Flow Chart for Derriving the DBMSDataType & Constraint for the PRIMARY KEY Column of a Table as per Requirements 5d-4.1

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

60 COLUMN/TABLE REQUIREMENT Requirement 5d-4.1: Primary Key Columns Data Type & Constraint Requirements. THE MOST IMPORTANT COLUMN DATA TYPE, CONSTRAINT & METADATA SELECTION YOU NEED TO MAKE FOR EVERY TABLE! EXECUTE THIS REQUIREMENT CAREFULLY PART 1 ( Requirement 5d-4.1 Go Do #1 – Review the Theory ) – Summary of the Theory to determine Primary Key Data Type: 1. As per the theory, the syntax we will use to derive the DBMS Data Type & Constraints is as follows: <Column Name> <DBMS Data Type> <Constraint List> 2. Requirement 5d-4.1 GO DO #1 – Review & follow the PRIMARY KEY FLOW CHART & PRIMARY KEY theory & Rules in Appendix C to execute this section.  Note that a lot of my examples contain answers to this project. But NOT all, so don’t copy blindly, analyze & review before deciding to leverage any of the answers of my examples. 3. SUMMARY of TOOLS & HIGH-LEVEL STPES TO SELECTING DATA TYPES FOR TABLE COLUMNS : 1) STEP #1 – The Tools Required: a) Tool #1 – The Normalized Logical Model Diagram available . b) Tool #2 – Have the Target DBMS (Oracle, MS SQL, MySQL, etc.) Data Type Table (numeric, character, date, time, BLOB, other, etc.) handy. Every DBMS has a data type set list in the DBMS documentation. I provide this listing in APPENDICES D & E of this project exam requirements . c) Tool #3 – Have 5 Design Guidelines for Data Dictionary Data Types and the PRIMARY KEY RULES #1, #2, #3a, #3b, #4, #5, #6 & #7 handy . See APPENDICES C . d) Tool #4 – Have your BRAIN ready to Think and be Creative!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

61 PART 2 ( Requirement 5d-4.1 Go Do #2 – Full Examples of Primary Keys that HAVE BUSINESS MEANING ) – Look at these Primary Key Data Type examples of using the PRIMARY KEY RULES for Primary Keys that HAVE Business Meaning to learn how to derive these Data Types:  Note the examples in this section are full examples that cover the thought process and rules to derive the DBMS Data Type & Constraints for a PRIMARY KEY.  Keep in mind that a lot of my examples contain answers to this project. But NOT all, so don’t copy blindly, analyze & review before deciding to leverage any of the answers of my examples.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

62 Microsoft SQL Server ( CST4708 Class Use These Examples ): 1. EXAMPLE #1 (Scenario #1: Primary Key Has BUSINESS MEANING and uses Maximum Size of Default MS SQL Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ You are designing the Data Type for the ReservationID Primary Key column of a RESERVATION TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ In this business, the ReservationID is used to identify a reservation . It appears in reports, in the customer confirmation email etc. Therefore, this Primary Key Has Business Meaning . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted in NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 4) Analysis of PRIMARY KEY RULE #3 – Analyze how reservations are used in this business and what makes business sense. For the Auto Rental Company , the value of the primary key ReservationID , can grow to the hundreds of millions of reservation transactions over the years! Even if we guess and be conservative in the numbers, if we assume that there will be 1000 reservations in the US alone daily, that is 365,000 a year and we multiply that by 10 countries that would be 3,650,000 . Therefore, the ReservationID column in this table can grow quite large. A business with such a dependency on reservations would want to make sure this value does not reach a limit , resulting in all reservations stopping because the database table reached a limit and can no longer make reservations anywhere in the world. That would be a disaster for this business, therefore this value needs to be large to scale for the next 20+ years . Therefore, we apply PRIMARY KEY RULE #3a which means an integer number from 1 to a MAXIMUM SIZE of the default value of the data type . 5) Based on the business analysis of PRIMARY KEY RULE #3a , and what makes BUSINESS SENSE , we decide to eliminate any concerns of reaching a LIMIT because of the concern to the impact to the business if this were to happen that we decide on the largest integer number data type available in Microsoft SQL Server which would be a BIGINT Data Type , whose default value can store an integer up to 9,223,372,036,854,775,807 as indicated in the Data Type Table for Microsoft SQL Server . This should provide enough room for 20+ years of new reservations added without worrying about reaching a limit. 6) We then Apply PRIMARY KEY RULE #7 to determine the CONSTRAINTS needed on this column and since ReservationID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax and no other CONSTRAINTS are required. 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the ReservationID Primary Key Column : ReservationID BIGINT PRIMARY KEY 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them, but for non-primary key data types you WILL NEED TO INCLUDE NOT NULL & others .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

63 2. EXAMPLE #2 (Scenario #2: Primary Key Has BUSINESS MEANING and uses LIMITED SIZE of Default MS SQL Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ You are designing the Data Type for the CompanyID Primary Key column of a COMPANY TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ The COMPANY TABLE stores ALL the records containing the data of the corporate companies that have a contract with the Auto Rental Company to use their services for renting vehicles for business travel for their Corporate Employees/Corporate Customers . ▪ In this business, the CompanyID is used as the number or ID to identify a Corporate Company . This Primary Key appears in reports, business applications, etc., which means it HAS BUSINESS MEANING . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted in NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 4) Analysis of PRIMARY KEY RULE #3 – Analyze how the CompanyID primary key is used in the business and what makes business sense. For the Auto Rental Company , the Company Table is used to store all the corporate companies that have a contract to be the Auto Rental Company of choice for their employee corporate travel rental. Therefore, this table stores all their Corporate Customers records as the rental company of choice for these companies, you could take an extreme use-case an say ALL companies in the world are your customers therefore, you select the MAXIMUM SIZE of the DBMS Data Type, which for Microsoft SQL Server is BIGINT , which is a number with a maximum size of 9,223,372,036,854,775,807 as indicated in the Data Type Table for Microsoft SQL Server . You ask yourself, does this choice MAKE BUSINESS SENSE? NO! A value of this size for the number of companies in the business is UNREALISTIC . Research shows that there are 45,508 listed companies in stock exchanges around the world. Therefore, we could choose our data type to only go up to 45,508 companies and stop. Nevertheless, we must think about storage costs & growth too. On the other hand, it would NOT be realistic that the Auto Rental Company would have all companies in the world as customers, so we must come to a happy medium, or do more research or thinking. The one fact for sure is that there is a LIMIT to the size of this data type since there are around 45,508+ listed companies. Another option in Microsoft SQL Server is the INT Data Type whose default value can grow up to 2,147,483,647 which is over 2 billion companies which is still unrealistic! Therefore, for the Company table primary key CompanyID , we need an integer number with a LIMIT that makes sense. What is the limit we need to choose? That is up to you to decide by doing more research or choose a limit that makes business sense. Since there is a LIMIT, we apply PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of the default value of the data type and NEVER REACHES THE MAXIMUMN!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

64 5) We continue our analysis to determine the size of the limit – Based on this business analysis, we executed PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of the default value of the data type and never reaches the MAX . In our analysis we looked at a maximum integer number of 45,508 , which is unrealistic for this type of Auto Rental Company to have all companies in the world, and we can be more conservative to save storage. What we need is a NUMBER BELOW 45,508 but above 10, 000 . Of course, we will make the decision NOT to use the Microsoft SQL Server INT Data Type whose default is 2,147,483,647 , but the SMALLINT data type maximum default size is 32,767 which is a slightly smaller capacity. Nevertheless, this MAX default value of the SMALLINT Data Type still may be an unrealistic number that the Auto Rental Company will have up to 32,767 companies as a customer, thus we can LIMIT this number even further . So, we will decide to choose the data type SMALLINT , but we will also ADD a CHECK CONSTRAINT to LIMIT its size further to 20,000 . This will be more than enough space to save storage. And still, this is a lot of companies, but we have room to grow if need be. But we made this decision. 6) We then apply PRIMARY KEY RULE #7 to determine the CONSTRAINT LIST needed on this column and since CompanyID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax. In addition, to LIMIT the size we also need to add a CHECK CONSTRAINT to LIMIT its size further to 20,000 . 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the CompanyID Primary Key Column : CompanyID SMALLINT PRIMARY KEY CHECK ( CompanyID between 1 and 20000 ) 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

65 3. EXAMPLE #3 (Scenario #3: Primary Key Has BUSINESS MEANING and uses LIMITED SIZE of Default MS SQL Server DBMSDataType & FOUND EXAMPLES or INSTANCES in the Business Requirements) ▪ You are designing the Data Type for the VehicleStatusID Primary Key column of a VEHICLESTATUS TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . This VEHICLESTATUS TABLE stores the records of the status of ALL VEHICLES owned by the Auto Rental Company . This Auto Rental Company needs to always know the status of where their VECHILCES. This TABLE contains this information. ▪ In this business, the VehicleStatusID is a number or ID to identify the Status of the Vehicle . This Primary Key appears in reports, business applications, etc., to identify the statuses of vehicles, which means it HAS BUSINESS MEANING . ▪ In this scenario, we follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted that we DID FIND A TABULAR LISTING of the Vehicle Status ID, Vehicle Status Description, and examples of these VALUES in the Business Requirements , as shown below: 2) This is great, we not only have an example of values for the PRIMARY KEY VehicleStatusID column but also examples of the NON-KEY column VehicleStatusDescription . Although our focus in this section is the Primary Key, we can also derive another column data type while performing this analysis. 3) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 4) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 5) Analysis of PRIMARY KEY RULE #3 – The tabular listing or examples of the primary key column VALUES showed in the first column , clearly show the business uses a number from 1 to 6 as a code to identify every UNIQUE status for a vehicle which means values of the Primary Key . So, examples or instances of the Primary Key are given . In addition, the Vehicle description for every UNIQUE status or Primary Key is listed on the right column . So, examples or instances of the Vehicle Status Descriptions are also given . This means we now know EVERY VALUE for both the Vehicle ID which is a LIMIT of 6 and Vehicle Status Description used by the Business . This is a blessing since we can now easily determine the data type for the entire VEHICLESTATUS TABLE . Since the data clearly shows there is a LIMIT of 6 for all VehicleStatusID , therefore, WE KNOW based on the example, that we need to apply PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

66 the default value of the data type and NEVER REACHES THE MAXIMUMN WHICH IN THIS CASE IS THE INTEGER 6 ! 6) We continue our analysis to determine the size of the limit – Therefore, we now know since the instances or the example tabular listing showed us a limit from 1 to 6 , and we HAVE THE LIMIT! Nevertheless, it would be smart to allow some room for growth, therefore, we will make the following choices: a. VehicleStatusID Primary Key – Since the values shown in the instances or examples of the Business Requirements are limited to numbers from 1 to 6, we choose a MS SQL Server Data Type that provides the LOWEST LIMIT possible, which is a TINYINT from 1 to 255 . This value work, but we need to make sure THIS MAKES BUSINESS SENSE! If we analyze this usage and ask the question WILL THIS VehicleStatusID Primary Key grow to 255? In other words, can there be up to 255 statuses for a Vehicle? Well, think about it, how many statuses can a vehicle have in a rental company? Common sense says, not many. The examples in the Business Requirements kind of cover them all. The only one I can think of now is UNKNOWN , but in the future, there could be a few more. To allow some room for growth we will allow for another 3 future statuses , so the decision is made for SIZE LIMIT to be an integer number from 1 to a 9 and NOT the MAXIMUM DEFAULT SIZE of the MS SQL Server TINYINT Data Type of 1 to 255 . To do this we will ADD a CHECK CONSTRAINT to LIMIT its size to 9 . b. VehicleStatusDescription (Non-Key) Column – While we are here, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column VehicleStatusDescription thought process. The instances examples shown in the tabular listing for VehicleStatusDescription shown in the Business Requirements are strings. Which variable string, therefore, a data type like VARCHAR(X) would be ideal. But what is the size of X? If you look at the largest string value, and add a little room for growth, you can determine the value of X . In this case, the largest string is VehicleStatusDescription Transfer to another Agency , which holds 26 characters including spaces . Thus, we can choose the value for X= 35 to take into account future growth, resulting in the Data Type VARCHAR (35) . For the CONSTRAINT LIST , since this column is REQUIRED, therefore, we must include the NOT NULL CONSTRAINT . 7) We then apply PRIMARY KEY RULE #7 to determine the CONSTRAINT LIST needed on this column and since VehicleStatusID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax. In addition, to LIMIT the size we also need to add a CHECK CONSTRAINT to LIMIT its size further to 9 . 8) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the VehicleStatusID Primary Key Column : VehicleStatusID TINYINT PRIMARY KEY CHECK( VehicleStatusID between 1 and 9 ) 9) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you d on’t need to specify them. 10) Below is an example of the datatype for the VehicleStatusDescription non-key Column, Data Type, size/range, and Constraints : VehicleStatusDescription VARCHAR( 35 ) NOT NULL 11) Note that for non-primary key data types you NEED TO INCLUDE NOT NUL or NULL constraints when it applies.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

67 ORACLE Server ( CST3604 Class Use These Examples ): 1. EXAMPLE #1 (Scenario #1: Primary Key Has BUSINESS MEANING and uses Maximum Size of Default ORACLE Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ You are designing the Data Type for the ReservationID Primary Key column of a RESERVATION TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ In this business, the ReservationID is used to identify a reservation . It appears in reports, in the customer confirmation email etc. Therefore, this Primary Key Has Business Meaning . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted in NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 4) Analysis of PRIMARY KEY RULE #3 – Analyze how reservations are used in this business and what makes business sense. For the Auto Rental Company , the value of the primary key ReservationID , can grow to the hundreds of millions of reservation transactions over the years! Even if we guess and be conservative in the numbers, if we assume that there will be 1000 reservations in the US alone daily, that is 365,000 a year and we multiply that by 10 countries that would be 3,650,000 . Therefore, the ReservationID column in this table can grow quite large. A business with such a dependency on reservations would want to make sure this value does not reach a limit , resulting in all reservations stopping because the database table reached a limit and can no longer make reservations anywhere in the world. That would be a disaster for this business, therefore this value needs to be large to scale for the next 20+ years . Therefore, we apply PRIMARY KEY RULE #3a which means an integer number from 1 to a MAXIMUM SIZE of the default value of the data type . 5) Based on the business analysis of PRIMARY KEY RULE #3a , and what makes BUSINESS SENSE , we decide to eliminate any concerns of reaching a LIMIT because of the concern to the impact to the business if this were to happen that we decide on the largest integer number data type available in ORACLE Server which would be a NUMBER Data Type , whose default value can store an integer up to 38 digit of precision or 99999999999999999999999999999999999999 as indicated in the Data Type Table for ORACLE Server . This is a very large number, too large a matter of fact, but a possible good choice that should provide enough room for 100+ years of new reservations added without worrying about reaching a limit. 6) We then Apply PRIMARY KEY RULE #7 to determine the CONSTRAINTS needed on this column and since ReservationID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax and no other CONSTRAINTS are required. 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the ReservationID Primary Key Column : ReservationID NUMBER PRIMARY KEY 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them, but for non-primary key data types you WILL NEED TO INCLUDE NOT NULL & others .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

68 2. EXAMPLE #2 (Scenario #2: Primary Key Has BUSINESS MEANING and uses LIMITED SIZE of Default ORACLE Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ You are designing the Data Type for the CompanyID Primary Key column of a COMPANY TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ The COMPANY TABLE stores ALL the records containing the data of the corporate companies that have a contract with the Auto Rental Company to use their services for renting vehicles for business travel for their Corporate Employees/Corporate Customers . ▪ In this business, the CompanyID is used as the number or ID to identify a Corporate Company . This Primary Key appears in reports, business applications, etc., which means it HAS BUSINESS MEANING . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted in NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 4) Analysis of PRIMARY KEY RULE #3 – Analyze how the CompanyID primary key is used in the business and what makes business sense. For the Auto Rental Company , the Company Table is used to store all the corporate companies that have a contract to be the Auto Rental Company of choice for their employee corporate travel rental. Therefore, this table stores all their Corporate Customers records as the rental company of choice for these companies, you could take an extreme use-case an say ALL companies in the world are your customers therefore, you select the MAXIMUM SIZE of the DBMS Data Type, which for ORACLE Server is the NUMBER Data Type whose default is a 38-digit number such as 99999999999999999999999999999999999999 , as indicated in the Data Type Table for Oracle Server . This number is in the trillions and unrealistic. You ask yourself, does this choice MAKE BUSINESS SENSE? NO! A value of this size for the number of companies in the business is UNREALISTIC . Research shows that there are 45,508 listed companies in stock exchanges around the world. Therefore, we could choose our data type to only go up to 45,508 companies and stop. Nevertheless, we must think about storage costs & growth too. On the other hand, it would NOT be realistic that the Auto Rental Company would have all companies in the world as customers, so we must come to a happy medium, or do more research or thinking. The one fact for sure is that there is a LIMIT to the size of this data type since there are around 45,508+ listed companies. Therefore, for the Company table primary key CompanyID , we need an integer number with a LIMIT that makes sense. What is the limit we need to choose? That is up to you to decide by doing more research or choose a limit that makes business sense. Since there is a LIMIT, we apply PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of the default value of the data type and NEVER REACHES THE MAXIMUMN!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

69 5) We continue our analysis to determine the size of the limit – Based on this business analysis, we executed PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of the default value of the data type and never reaches the MAX . In our analysis we looked at a maximum integer number of 45,508 , which is unrealistic for this type of Auto Rental Company to have all companies in the world, and we can be more conservative to save storage. What we need is a NUMBER BELOW 45,508 but above 10, 000 . Of course, we will make the decision NOT to use the ORACLE Server is the NUMBER Data Type whose default is a 38-digit number such as 99999999999999999999999999999999999999 . We could limit the NUMBER Data Type to a 4-DIGIT NUMBER using NUMBER(4) Data Type , nevertheless, this has a MAX of 9,999 , which is too small since under 10,000. Therefore we chose the NUMBER(5) Data Type with a MAX of 99,999 . Nevertheless, this MAX is an unrealistic number that the Auto Rental Company will have up to 99,999 companies as customers, thus we can LIMIT this number even further by ADDING a CHECK CONSTRAINT to LIMIT its size to 20,000 . This will be more than enough space to save storage. And still, this is a lot of companies, but we have room to grow if need be. 6) We then apply PRIMARY KEY RULE #7 to determine the CONSTRAINT LIST needed on this column and since CompanyID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax. In addition, to LIMIT the size we also need to add a CHECK CONSTRAINT to LIMIT its size further to 20,000 . 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the CompanyID Primary Key Column : CompanyID NUMBER(5) PRIMARY KEY CHECK ( CompanyID between 1 and 20000 ) 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

70 3. EXAMPLE #3 (Scenario #3: Primary Key Has BUSINESS MEANING and uses LIMITED SIZE of Default ORACLE Server DBMSDataType & FOUND EXAMPLES or INSTANCES in the Business Requirements) ▪ You are designing the Data Type for the VehicleStatusID Primary Key column of a VEHICLESTATUS TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . This VEHICLESTATUS TABLE stores the records of the status of ALL VEHICLES owned by the Auto Rental Company . This Auto Rental Company needs to always know the status of where their VECHILCES. This TABLE contains this information. ▪ In this business, the VehicleStatusID is a number or ID to identify the Status of the Vehicle . This Primary Key appears in reports, business applications, etc., to identify the statuses of vehicles, which means it HAS BUSINESS MEANING . ▪ In this scenario, we follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted that we DID FIND A TABULAR LISTING of the Vehicle Status ID, Vehicle Status Description, and examples of these VALUES in the Business Requirements , as shown below: 2) This is great, we not only have an example of values for the PRIMARY KEY VehicleStatusID column but also examples of the NON-KEY column VehicleStatusDescription . Although our focus in this section is the Primary Key, we can also derive another column data type while performing this analysis. 3) The FLOW CHART leads us to PRIMARY KEY RULE #2a , where we determine the primary key HAS business meaning . 4) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #3 to determine whether the DBMS Data Type will reach the MAXIMUM SIZE of its default size OR the be LIMITED and never reach the maximum default SIZE of DBMS . In the next step we analyze and make a choice. 5) Analysis of PRIMARY KEY RULE #3 – The tabular listing or examples of the primary key column VALUES showed in the first column , clearly show the business uses a number from 1 to 6 as a code to identify every UNIQUE status for a vehicle which means values of the Primary Key . So, examples or instances of the Primary Key are given . In addition, the Vehicle description for every UNIQUE status or Primary Key is listed on the right column . So, examples or instances of the Vehicle Status Descriptions are also given . This means we now know EVERY VALUE for both the Vehicle ID which is a LIMIT of 6 and Vehicle Status Description used by the Business . This is a blessing since we can now easily determine the data type for the entire VEHICLESTATUS TABLE . Since the data clearly shows there is a LIMIT of 6 for all VehicleStatusID , therefore, WE KNOW based on the example, that we need to apply PRIMARY KEY RULE #3b which means an integer number from 1 to a LIMITED SIZE of

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

71 the default value of the data type and NEVER REACHES THE MAXIMUMN WHICH IN THIS CASE IS THE INTEGER 6 ! 6) We continue our analysis to determine the size of the limit – Therefore, we now know since the instances or the example tabular listing showed us a limit from 1 to 6 , and we HAVE THE LIMIT! Nevertheless, it would be smart to allow some room for growth, therefore, we will make the following choices: a. VehicleStatusID Primary Key – Since the values shown in the instances or examples of the Business Requirements are limited to numbers from 1 to 6, we choose a ORACLE Server Data Type that provides the LOWEST LIMIT possible, which is a NUMBER(1) or number from 1 to 9 . This value work, but we need to make sure THIS MAKES BUSINESS SENSE! If we analyze this usage and ask the question WILL THIS VehicleStatusID Primary Key grow to 9? In other words, can there be up to 9 statuses for a Vehicle? Well, looking at the instances or examples provided by the Business Requirements , there are only 6 status at the moment used by the business, so NUMBER(1) covers the 6 with an extra 3 for future growth . We could also use a NUMBER(2) with a MAX of 99 and ADD a CHECK CONSTRAINT to LIMIT its size further to 20 , thus allowing for 20 statuses . In this case, we make the decision to stay with NUMBER(1) allowing for up to 9 statuses, the current 6 and 3 more for future growth . b. VehicleStatusDescription (Non-Key) Column – While we are here, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column VehicleStatusDescription thought process. The instances examples shown in the tabular listing for VehicleStatusDescription shown in the Business Requirements are strings. Which variable string, therefore, a data type like VARCHAR(X) would be ideal. But what is the size of X? If you look at the largest string value, and add a little room for growth, you can determine the value of X . In this case, the largest string is VehicleStatusDescription Transfer to another Agency , which holds 26 characters including spaces . Thus, we can choose the value for X= 35 to take into account future growth, resulting in the Data Type VARCHAR2 (35) . For the CONSTRAINT LIST , since this column is REQUIRED, therefore, we must include the NOT NULL CONSTRAINT . 7) We then apply PRIMARY KEY RULE #7 to determine the CONSTRAINT LIST needed on this column and since VehicleStatusID is the PRIMARY KEY column, we need to include the PRIMARY KEY CONSTRAINT in our syntax. In addition, to LIMIT the size we also need to add a CHECK CONSTRAINT to LIMIT its size further to 9 . 8) Below are the results of our analysis for the Primary Key Column DBMSDataType , size/range , and Constraint List for the VehicleStatusID Primary Key Column : VehicleStatusID NUMBER(1) PRIMARY KEY 9) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them. 10) Below is an example of the datatype for the VehicleStatusDescription non-key Column, Data Type, size/range, and Constraints : VehicleStatusDescription VARCHAR2( 35 ) NOT NULL 11) Note that for non-primary key data types you NEED TO INCLUDE NOT NUL or NULL constraints when it applies.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

72 PART 3 ( Requirement 5d-4.1 Go Do #3 ) – EXECUTE This Requirement to Design the Data Types for ALL PRIMARY KEYS that HAVE Business Meaning using the PRIMARY KEY FLOW CHART: 1. Requirement 5d-4.1 Go Do #3a – From Analysis of the Business Requirements and review of the Normalized Logical Model, we have identified the 18 Tables in our Normalized Logical Model whose PRIMARY KEY HAVE Business Meaning and you need to DERIVE the DATA TYPES & CONSTRAINT for the Primary Key of EACH OF THESE TABLES. ▪ Go Do #3a EXECUTION – For Each of the 18 out of 33 tables listed below, follow the FLOW CHART & theory and examples in this document to create the Primary keys for the following Tables whose PRIMARY KEYS HAVE Business Meaning: 1) COMPANY Table CompanyID – The business requirements stated that the company table is identified by a unique ID using a specific number used by the business thus has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 2) DRIVERLICENSE Table DriverLicenseNumber – The DriverLicence table is identified by a unique DriverLicenseNumber . This is an alphanumeric number that has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 3) CREDITCARDMERCHANT Table MerchantCode – The CreditCardMerchant table is identified by a unique MerchantCode . This is an INTEGER number that has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 4) RESERVATION Table ReservationID – The business requirements stated that reservation ID is used by the customer and business to identify the reservation, has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

73 5) RENTAL Table RentalID – The business requirements stated that reservation ID is used by the customer and business to identify the reservation, has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 6) RENTALAGENCY Table RentalAgencyID – The business requirements stated that rental agencies are identified by a unique ID using a specific number used by the business thus has business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 7) TRANSMISSIONTYPE Table TransmissionTypeID – The business requirements provide a tabular listing of the Transmission Type IDs they use to identify the type of transmission a vehicle has; thus, they use the primary key codes to identify a transmission code, thus this primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 8) VEHICLESTATUS Table VehicleStatusID – The business requirements provide a tabular listing of the Vehicle Status IDs they use; thus, they use the primary key codes to identify a vehicle status, thus this primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 9) VEHICLERENTALCATEGORY Table VehicleRentalCategoryID – The business requirements provide a tabular listing of the Vehicle Rental Categories IDs they use to identify the category; thus, they use the primary key codes to identify a category, thus this primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 10) RESERVATIONSTATUS Table ReservationStatusID – The business requirements provide a tabular listing of the Reservation Status IDs they use to identify the status of a reservation; thus, they use the primary key codes to identify the status which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 11) RENTALSTATUS Table RentalStatusID – The business requirements provide a tabular listing of the Rental Status IDs they use to identify the status of a rental; thus, they use the primary key codes to identify the status which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 12) RENTALINSURANCEOPTION Table InsuranceOptionID – The business requirements provide a tabular listing of the Insurance Option IDs they use to identify a specific insurance option; thus, they use the primary key codes to identify the option which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

74 13) FUELOPTION Table RentalFuelOptionID – The business requirements provide a tabular listing of the Fuel Option IDs they use to identify a specific fuel option; thus, they use the primary key codes to identify the option which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 14) TRANSPORTSTATUS Table TransportStatusID – The business requirements provide a tabular listing of the Transport Status IDs they use to identify a specific the transport status; thus, they use these primary key codes to identify the option which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 15) TRANSPORTREASON Table TransportReasonID – The business requirements provide a tabular listing of the Transport Reason IDs they use to identify a specific the transport reason; thus, they use these primary key codes to identify the option which means the primary key has business meaning. Review the INSTANCE TABULAR INFORMATION in the business requirements to determine the data type for primary key . 16) USSTATE Table StateID – The application technical requirements User-Interface requirements indicate the STATE fields in an address requires the state codes to be prepopulated in the field or combo-box/list box . The USSTATE table stores the state codes and names of each state to support the UI. The listing of US States is shown in the requirements to have business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 17) COUNTRY Table CountryID – The application technical requirements User- Interface requirements indicate the COUNTRY fields in an address requires the country names be prepopulated in the field or combo-box/list box . The COUNTRY table stores the names & code for each country to support the UI. The listing of Countries shown in the requirements to have business meaning. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key . 18) EMPLOYEE Table EmployeeID – the Employee ID has business meaning since the business uses the Employee ID to search, report and manage employees in the business. Review the business requirements to identify if any INSTANCE INFORMATION is provided, otherwise use PRIMARY KEY RULES to guide you to decide the datatype for this primary key .  CST4708 Class GO DO #3a – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  IMPORTANT – Don’t forget to apply DESIGN GUIDELINE DATA TYPE RULE #2 & Requirement 5d-4.20 to Check the Business Requirements for possible clues to Data Type & Constraints .  CST3604 Class GO DO #3a – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  IMPORTANT – Don’t forget to apply DESIGN GUIDELINE DATA TYPE RULE #2 & Requirement 5d-4.20 to Check the Business Requirements for possible clues to Data Type & Constraints .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

75 2. Requirement 5d-4.1 Go Do #3b – From EXECUTE SPECIAL CASE where the Primary Key HAS business meaning, and the Primary Key DBMSDataType IS NOT an INTEGER NUMBER but a STRING OF CHARACTERS DATA TYPE. ▪ Go Do #3b EXECUTION – This is a SPECIAL CASE where the Primary Key HAS business meaning BUT IS NOT A NUMBER . As per previous discussion, the recommendation for primary key is an INTEGER NUMBER data type as per the PRIMARY KEY RULE #1 , nevertheless this is not set in stone, there are cases where CHAR or STRING OF CHARACTERS DATA TYPE or others, are the best option. The following PRIMARY KEY(s) & Table(s) have been identified as candidate for a STRING OF CHARACTERS data type and a requirement for this project: 1) CREDITCARD Table CreditCardNumber – a credit card number is a numeric or can be looked at as alphanumeric number used in business transaction reports etc. Therefore, since this number is used throughout the business to identify the payment method for renting vehicles in reports and the application, etc., IT HAS BUSINESS MEANING! Whether a credit card number should be a numeric integer, or an alphanumeric string integer is the topic of many debates . In this project, for the credit card table primary key CreditCardNumber , the requirement is to use a Variable String of Characters SIZE 16 Primary Key . MAKE THIS PRIMARY KEY A VARIABLE STRING OF CHARACTERS SIZE 16 .  CST4708 Class GO DO #3b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO #3b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

76 PART 4 ( Requirement 5d-4.1 Go Do #4 ) – Look at these Data Type Examples of Primary Key with NO Business Meaning using the PRIMARY KEY RULES for Primary Keys that HAVE NO Business Meaning to learn how to derive these types of Primary Keys Data Types:  Note the examples in this section are full examples and cover the thought process and rules to derive the DBMS Data Type & Constraints for a PRIMARY KEY .  Keep in mind that a lot of my examples contain answers to this project. But NOT all, so don’t copy blindly, analyze & review before deciding to leverage any of the answers of my examples.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

77 Microsoft SQL Server ( CST4708 Class Use These Examples ): 1. EXAMPLE #1 ( Primary Key Has NO BUSINESS MEANING thus an IDENTITY and uses Maximum Size of Default MS SQL Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ In this scenario, you are designing the Data Type for the CustomerID Primary Key column of a CUSTOMER TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ The CustomerID Primary Key column uniquely identifies a CUSTOMER RECORD/ROW in the CUSTOMER TABLE . ▪ Nevertheless, in this business, for all customer business related transactions, it is the DriverLicenseNumber that is used to identify a customer when searching a CUSTOMER , all CUSTOMER transactions, reporting, etc., NOT THE CustomerID Primary Key column! Therefore, CustomerID Primary Key column HAS NO Business Meaning in this business, since CustomerID is used INTERNALLY BY THE APPLICATION & DBMS SYSTEM and never used by the business to associate a customer since DriverLicenseNumber has this role . ▪ We could consider using the DriverLicenseNumber number as the Primary Key since this number is UNIQUE , but this number has two important characteristics that affects this decision : 1) is an ALPHANUMERIC number or STRING OF CHARACTERS and will result in performance issues when executing SQL QUERIES that JOIN multiple tables in the future , and as you recall PRIMARY KEY RULE #1 stated a Primary Key should be an integer number as per best practice and only use a CHAR, STRING OF CHARACTERS, etc., only under special situations. 2) There is NO NEED to DEVELOP A NUMBER SYSTEM TO GENERATE THE VALUE of a Driver’s License Number , since the VALUE ALREADY EXISTS in the physical Driver’s License Card carried by the CUSTOMER which was GENERATED by the Motor Vehicle Agency in every COUNTRY . DriverLicenseNumber number is a Low-Hanging-Fruit for use in identifying , searching , and all CUSTOMER transactions . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART & applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DATA TYPE RULE #1 showed NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2b , where we determine the primary key HAS NO business meaning since is the DriverLicenseNumber number that has the business meaning. 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #4 which indicates the PRIMARY KEY is a DBMSDataType with the IDENTITY keyword and with the MAXIMUM default size of the chosen DBMSDataType . 4) Analysis of PRIMARY KEY RULE #4 – We Analyze how this primary key CustomerID is used by the business and what makes business sense. For the Auto Rental Company , the value of the primary key CustomerID is NOT SEEN BY THE USERS OR BUSINESS with NO BUSINESS MEANING , therefore, we need to SELECT the appropriate DBMSDataType and ADD the keyword IDENTITY as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

78 a) BUT WHAT IS THE APPROPRIATE DBMSDataType ? This simple since PRIMARY KEY RULE #4 indicates that an IDENTITY is an AUTO-INCREMENTED INTEGER NUMBER STARTING FROM 1 THAT IS AUTOMATICALLY ADDED BY THE DBMS FOR YOU . This means, the DBMSDataType is an INTEGER NUMBER data type. PRIMARY KEY RULE #4 also indicates to use the MAXIMUM default size of the chosen INTEGER NUMBER DBMSDataType . b) The question now is which integer number or Data Type should we use in Microsoft SQL Server, INT, BIGINT, SMALLINT, TYNYINT, etc., for the IDENTITY ? We need to analyze WHAT MAKES BUSINESS SENSE! Analyzing the scenario, the world’s population is 7.9 billion people. Realistically, you cannot assume that all the 7.9 billion people will be customers of Auto Rental Company , therefore we need a smaller data type then one that can hold 7.9 billion people . That rules out the Microsoft SQL Server BIGINT DBMSDataType . At the same time, we don’t want to fall short either, this business has some high goals. It makes sense to use the Microsoft SQL Server INT Data Type whose default is 2,147,483,647 , thus giving a range in the 2 billion customers . This should provide enough room for many years of adding new customers without reaching a limit. c) Based on this business analysis of PRIMARY KEY RULE #4 , we concluded that we would use the 1 to a MAXIMUM SIZE of the default value of the Microsoft SQL Server INT Data Type data type . This scenario eliminates any concerns of reaching a LIMIT , since the Microsoft SQL Server INT Data Type default value can store an integer up to 2,147,483,647 customer IDs as indicated by the official Data Type Table for Microsoft SQL Server (see Appendix D) . This should provide enough room for 20+ years of new customers added without worrying about reaching a limit. 5) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the CustomerID Primary Key Column : CustomerID INT IDENTITY PRIMARY KEY 6) An IDENTITY Primary Key column can be seeded with a starting number and increment value of the IDENTITY number if desired. Below is an example of an identity starting at 111111 and incrementing by 1 . Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the VehicleStatusID Primary Key Column seeding the starting number using 111111 and incrementing by 1 : CustomerID INT IDENTITY ( 111111, 1 ) PRIMARY KEY 7) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them, but for non-primary key data types you WILL NEED TO INCLUDE NOT NULL & others .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

79 2. EXAMPLE #2 ( Primary Key Has NO BUSINESS MEANING thus an IDENTITY and uses Maximum Size of Default MS SQL Server DBMSDataType & FOUND EXAMPLES or INSTANCES in the Business Requirements) ▪ You are designing the Data Type for the DiscountID Primary Key column of a DISCOUNT TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ In this business, this DISCOUNT TABLE stores ALL the data related to discounts or promotional code such as Discounts ID , Discount Code and Discount Code Description offered to customers in various advertising forums, such as newspapers, TV, ecommerce sites, social media etc. ▪ The DiscountID is the UNIQUE ID used to identify each Discount Code . This DiscountID Primary Key DOES NOT appear in reports, business applications, etc., which means it HAS NO BUSINESS MEANING and only used internally by the Application and DBMS system! ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART & applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted that we DID FIND A TABULAR LISTING of the Discount ID, Discount Code, Discount Code Description, and examples of these VALUES in the Business Requirements , as shown below: 2) This is great, we not only have an example of values for the PRIMARY KEY DiscountID column but also examples of the NON-KEY column DiscountCode and the NON-KEY column DiscountCodeDescription . Although our focus in this section is the Primary Key, we can also derive two additional columns data type while performing this analysis. 3) The FLOW CHART leads us to PRIMARY KEY RULE #2b , where we determine the primary key HAS NO business meaning . 4) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #4 which indicates the PRIMARY KEY is a DBMSDataType with the IDENTITY keyword and with the MAXIMUM default size of the chosen DBMSDataType . In the next step we analyze and make a choice. Discount ID Discount Code Discount Code Description 1234.. AAA9970054 AAA Membership Discount - 25% off base rate plus 10% donated for breast cancer research. 5678.. GOV8756921 Government Employee Discount - 30% off base rate 9101.. STA3415632 State Employee Discount for 25% off base rate 1213.. VET2055179 Veteran Discount 35% off base rate Plus 10% donation to ve teran’s family fund. Etc.. Etc.. Etc..

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

80 5) Analysis of PRIMARY KEY RULE #4 – We Analyze how this primary key DiscountID is used by the business and what makes business sense. For the Auto Rental Company , the value of the primary key DiscountID is NOT SEEN BY THE USERS OR BUSINESS with NO BUSINESS MEANING , therefore, we need to SELECT the appropriate DBMSDataType and ADD the keyword IDENTITY as follows: a) As stated, this tabular listing shows in the first column that the Discount ID Primary Key column is a number with HAS NO Business Meaning , so this value is RANDOM , and we agreed is an IDENTITY Data Type. b) For the second column , it shows the Discount Code column uses an ALPHANUMERIC CODE of 10 characters only and all values shown are fixed-10 characters formatted number, no more, no less . c) Finally, the third column shows a Discount Code Description that is a VARIABLE-LENGTH String of Characters, which some are shorter and longer than others . d) Therefore, from the examples or instances provided by this table in the Business Requirements we have information to make determining the Data Type of all three columns of the DISCOUNT TABLE . This is a blessing since we can now easily determine the data type for this DISCOUNT TABLE . 6) Based on the previous analysis of the VALUE EXAMPLES OR INSTANCES found in the Business Requirements for Discount ID, Discount Code, Discount Code Description, we make the following choices : a. DiscountID Primary Key – Since the values shown in the instances or examples of the Business Requirements, the tabular listing shows the Discount ID Primary Key column is a number with HAS NO Business Meaning , thus the APPROPRIATE DBMSDataType as per PRIMARY KEY RULE #4 is an IDENTITY AUTO- INCREMENTED INTEGER NUMBER STARTING FROM 1 THAT IS AUTOMATICALLY ADDED BY THE DBMS FOR YOU . This means, the DBMSDataType is an INTEGER NUMBER data type. PRIMARY KEY RULE #4 also indicates to use the MAXIMUM default size of the chosen INTEGER NUMBER DBMSDataType . In this case, we are dealing with the UNIQUE DiscountID that identifies a Discount Codes that will be offered to customers in various advertising forums, such as newspapers, TV, ecommerce sites, social media etc. This means there will be a lot of DISCONTS over the years. The question to ask is which integer number or Data Type should we use in Microsoft SQL Server , INT ( MAX 2,147,483,647 ), BIGINT ( MAX 9,223,372,036,854,775,807 ), SMALLINT ( MAX 32,767 ), TYNYINT ( MAX 155 ), etc., for the IDENTITY ? If you analyze the scenario, there are going to be quite several DISCOUTNS over the years. There will be NEW DISCOUNT CODES , and some DISCOUNTS will be expired and possibly deleted. The BIGINT ( MAX 9,223,372,036,854,775,807 ) will be too big, SMALLINT ( MAX 32,767 ) is too small, therefore we will go with the Microsoft SQL Server INT Data Type whose default is 2,147,483,647 which is in the billions and should be enough. That is our decision.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

81 b. DiscountCode (Non-Key) Column – While we are here, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column DiscountCode thought process. The instances examples shown in the tabular listing for DiscountCode shown in the Business Requirements is a FIXED-LENGTH ALPHANUMERIC CHARACTER SIZE 10 , which a FIXED STRING data type since the DiscountCode will always be the length of 10 . Thus, resulting in the Data Type CHAR (10) , with the NOT NULL constraint since the DiscountCode value is required column based on the Normalized Logical & EER Models . c. DiscountCodeDescription (Non-Key) Column – Also, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column DiscountCodeDescription . The instances examples shown in the tabular listing for DiscountCodeDescription shows an alphanumeric VARIABLE-LENGTH ALPHANUMERIC CHARACTER string , which aligns to DBMSDataType VARCHAR (X) . But what is the size of X? If you look at the largest string value, and add a little room for growth, you can determine the value of X . In this case, the largest string is DiscountCodeDescription is AAA Membership Discount – 25% off base rate plus 10% donated to breast cancer research , which holds 86 characters including spaces . Thus, we can choose the value for X= 150 to take into account future growth, resulting in the Data Type VARCHAR (150) . In addition, we include the NOT NULL constraint since the DiscountCodeDescription value is required column based on the Normalized Logical & EER Models . 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the DiscountID Primary Key Column : DiscountID INT IDENTITY PRIMARY KEY 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL Constraint , which you don’t need to specify it. 9) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the NON-KEY COLUMN DiscountCode : DiscountCode CHAR( 10 ) NOT NULL 10) Note that for non-primary key data types you WILL NEED TO INCLUDE NOT NUL or NULL constraints when it applies. 11) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the NON-KEY COLUMN DiscountCodeDescription : DiscountCodeDescription VARCHAR( 150 ) NOT NULL 12) Note that for non-primary key data types you WILL NEED TO INCLUDE NOT NUL or NULL constraints when it applies.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

82 Oracle Server ( CST3604 Class Use These Examples ): 1. EXAMPLE #1 ( Primary Key Has NO BUSINESS MEANING thus an IDENTITY and uses Maximum Size of Default ORACLE Server DBMSDataType & NO EXAMPLES or INSTANCES found in the Business Requirements) ▪ In this scenario, you are designing the Data Type for the CustomerID Primary Key column of a CUSTOMER TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ The CustomerID Primary Key column uniquely identifies a CUSTOMER RECORD/ROW in the CUSTOMER TABLE . ▪ Nevertheless, in this business, for all customer business related transactions, it is the DriverLicenseNumber that is used to identify a customer when searching a CUSTOMER , all CUSTOMER transactions, reporting, etc., NOT THE CustomerID Primary Key column! Therefore, CustomerID Primary Key column HAS NO Business Meaning in this business, since CustomerID is used INTERNALLY BY THE APPLICATION & DBMS SYSTEM and never used by the business to associate a customer since DriverLicenseNumber has this role . ▪ We could consider using the DriverLicenseNumber number as the Primary Key since this number is UNIQUE , but this number has two important characteristics that affects this decision : 1) is an ALPHANUMERIC number or STRING OF CHARACTERS and will result in performance issues when executing SQL QUERIES that JOIN multiple tables in the future , and as you recall PRIMARY KEY RULE #1 stated a Primary Key should be an integer number as per best practice and only use a CHAR, STRING OF CHARACTERS, etc., only under special situations. 2) There is NO NEED to DEVELOP A NUMBER SYSTEM TO GENERATE THE VALUE of a Driver’s License Number , since the VALUE ALREADY EXISTS in the physical Driver’s License Card carried by the CUSTOMER which was GENERATED by the Motor Vehicle Agency in every COUNTRY . DriverLicenseNumber number is a Low-Hanging-Fruit for use in identifying , searching , and all CUSTOMER transactions . ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART & applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DATA TYPE RULE #1 showed NO examples in the Business Requirements . 2) The FLOW CHART leads us to PRIMARY KEY RULE #2b , where we determine the primary key HAS NO business meaning since is the DriverLicenseNumber number that has the business meaning. 3) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #4 which indicates the PRIMARY KEY is a DBMSDataType with the IDENTITY keyword and with the MAXIMUM default size of the chosen DBMSDataType . 4) Analysis of PRIMARY KEY RULE #4 – We Analyze how this primary key CustomerID is used by the business and what makes business sense. For the Auto Rental Company , the value of the primary key CustomerID is NOT SEEN BY THE USERS OR BUSINESS with NO BUSINESS MEANING , therefore, we need to SELECT the appropriate DBMSDataType and ADD the keyword IDENTITY as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

83 a) BUT WHAT IS THE APPROPRIATE DBMSDataType ? This simple since PRIMARY KEY RULE #4 indicates that an IDENTITY is an AUTO-INCREMENTED INTEGER NUMBER STARTING FROM 1 THAT IS AUTOMATICALLY ADDED BY THE DBMS FOR YOU . This means, the DBMSDataType is an INTEGER NUMBER data type. PRIMARY KEY RULE #4 also indicates to use the MAXIMUM default size of the chosen INTEGER NUMBER DBMSDataType . b) The question now is which integer number or Data Type should we use in Oracle Server, NUMBER or NUMBER (X) for the IDENTITY ? Also, WHAT IS X? We need to analyze WHAT MAKES BUSINESS SENSE! Analyzing the scenario, the world’s population is 7.9 billion people. Realistically, you cannot assume that all the 7.9 billion people will be customers of Auto Rental Company , therefore we need a smaller data type than the DEFAULT ORACLE NUMBER Data Type which is a number whose default size is a 38-digit number such as 99999999999999999999999999999999999999 , which is in the trillions and unrealistic, thus it does not make business sense to use the ORACLE NUMBER Data Type . That rules out the ORACLE NUMBER DBMSDataType . At the same time, we don’t want to fall short either, this business has some high goals. c) Based on this business analysis of PRIMARY KEY RULE #4 , we concluded that we would use the 1 to a MAXIMUM SIZE of the default value of the OracleServer INT Data Type data type . This scenario eliminates any concerns of reaching a LIMIT , since the Microsoft SQL Server INT Data Type default value can store an integer up to 2,147,483,647 customer IDs as indicated by the official Data Type Table for Microsoft SQL Server (see Appendix D) . This should provide enough room for 20+ years of new customers added without worrying about reaching a limit. d) Based on this business analysis of PRIMARY KEY RULE #4 , we could use the ORACLE Server NUMBER Data Type with a LIMITED 9 digit NUMBER such as a 999,999,999 , which in Oracle Server would be a NUMBER (9) thus giving a range close to 1 billion maximum customers . But to be on the safe side we may want to go bigger, therefore the next option is 9,999,999,999 , which is Oracle Server would be a NUMBER (10) thus giving a range close to 9 billion customers . This is still very large number but, should provide enough room for many years of adding new customers without reaching a limit. 5) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the CustomerID Primary Key Column : CustomerID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY 6) An IDENTITY Primary Key column can be seeded with a starting number and increment value of the IDENTITY number if desired. Below is an example of an identity starting at 111111 and incrementing by 1 . Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the VehicleStatusID Primary Key Column seeding the starting number using 111111 and incrementing by 1 : CustomerID NUMBER(10) GENERATED ALWAYS AS IDENTITY START WITH 111111 INCREMENT BY 1 PRIMARY KEY 7) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL & UNIQUE Constraints , which you don’t need to specify them, but for non-primary key data types you WILL NEED TO INCLUDE NOT NULL & others .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

84 2. EXAMPLE #2 ( Primary Key Has NO BUSINESS MEANING thus an IDENTITY and uses Maximum Size of Default MS SQL Server DBMSDataType & FOUND EXAMPLES or INSTANCES in the Business Requirements) ▪ You are designing the Data Type for the DiscountID Primary Key column of a DISCOUNT TABLE that exists in the DATABASE DESIGN & IMPLEMENTATION of an Auto Rental Company . ▪ In this business, this DISCOUNT TABLE stores ALL the data related to discounts or promotional code such as Discounts ID , Discount Code and Discount Code Description offered to customers in various advertising forums, such as newspapers, TV, ecommerce sites, social media etc. ▪ The DiscountID is the UNIQUE ID used to identify each Discount Code . This DiscountID Primary Key DOES NOT appear in reports, business applications, etc., which means it HAS NO BUSINESS MEANING and only used internally by the Application and DBMS system! ▪ We follow the PRIMARY KEY DATA TYPE & CONSTRATIN FLOW CHART PROCESS STEPS , which include 1) FIRST applying DESIGN GUIDELINE DATA TYPE RULE #2 to identify if the BUSINESS REQUIREMENTS has examples of values for the Primary Key, and 2) we follow the FLOW CHART & applying PRIMARY KEY RULES #1 through #7 and 3) what MAKES BUSINESS SENSE & REASONING/LOGIC . The results are as follows: 1) DESIGN GUIDELINE DATA TYPE RULE #2 - resulted that we DID FIND A TABULAR LISTING of the Discount ID, Discount Code, Discount Code Description, and examples of these VALUES in the Business Requirements , as shown below: 2) This is great, we not only have an example of values for the PRIMARY KEY DiscountID column but also examples of the NON-KEY column DiscountCode and the NON-KEY column DiscountCodeDescription . Although our focus in this section is the Primary Key, we can also derive two additional columns data type while performing this analysis. 3) The FLOW CHART leads us to PRIMARY KEY RULE #2b , where we determine the primary key HAS NO business meaning . 4) The FLOW CHART then leads us to EXECUTE PRIMARY KEY RULE #4 which indicates the PRIMARY KEY is a DBMSDataType with the IDENTITY keyword and with the MAXIMUM default size of the chosen DBMSDataType . In the next step we analyze and make a choice. Discount ID Discount Code Discount Code Description 1234.. AAA9970054 AAA Membership Discount - 25% off base rate plus 10% donated for breast cancer research. 5678.. GOV8756921 Government Employee Discount - 30% off base rate 9101.. STA3415632 State Employee Discount for 25% off base rate 1213.. VET2055179 Veteran Discount 35% off base rate Plus 10% donation to veteran’s family fund. Etc.. Etc.. Etc..

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

85 5) Analysis of PRIMARY KEY RULE #4 – We Analyze how this primary key DiscountID is used by the business and what makes business sense. For the Auto Rental Company , the value of the primary key DiscountID is NOT SEEN BY THE USERS OR BUSINESS with NO BUSINESS MEANING , therefore, we need to SELECT the appropriate DBMSDataType and ADD the keyword IDENTITY as follows: a) As stated, this tabular listing shows in the first column that the Discount ID Primary Key column is a number with HAS NO Business Meaning , so this value is RANDOM , and we agreed is an IDENTITY Data Type. b) For the second column , it shows the Discount Code column uses an ALPHANUMERIC CODE of 10 characters only and all values shown are fixed-10 characters formatted number, no more, no less . c) Finally, the third column shows a Discount Code Description that is a VARIABLE-LENGTH String of Characters, which some are shorter and longer than others . d) Therefore, from the examples or instances provided by this table in the Business Requirements we have information to make determining the Data Type of all three columns of the DISCOUNT TABLE . This is a blessing since we can now easily determine the data type for this DISCOUNT TABLE . 6) Based on the previous analysis of the VALUE EXAMPLES OR INSTANCES found in the Business Requirements for Discount ID, Discount Code, Discount Code Description, we make the following choices : a. DiscountID Primary Key – Since the values shown in the instances or examples of the Business Requirements, the tabular listing shows the Discount ID Primary Key column is a number with HAS NO Business Meaning , thus the APPROPRIATE DBMSDataType as per PRIMARY KEY RULE #4 is an IDENTITY AUTO- INCREMENTED INTEGER NUMBER STARTING FROM 1 THAT IS AUTOMATICALLY ADDED BY THE DBMS FOR YOU . This means, the DBMSDataType is an INTEGER NUMBER data type. PRIMARY KEY RULE #4 also indicates to use the MAXIMUM default size of the chosen INTEGER NUMBER DBMSDataType . In this case, we are dealing with the UNIQUE DiscountID that identifies a Discount Codes that will be offered to customers in various advertising forums, such as newspapers, TV, ecommerce sites, social media etc. This means there will be a lot of DISCONTS over the years. The question now is which integer number or Data Type should we use in Oracle Server, NUMBER or NUMBER (X) for the IDENTITY ? Also, WHAT IS X? We need to analyze WHAT MAKES BUSINESS SENSE! To simplify management of the discount ids we will use the DEFAULT ORACLE NUMBER Data Type which is a number whose default size is a 38-digit number such as 99999999999999999999999999999999999999 , which is in the trillions and although unrealistic, we can set this and forget it! That is our decision.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

86 b. DiscountCode (Non-Key) Column – While we are here, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column DiscountCode thought process. The instances examples shown in the tabular listing for DiscountCode shown in the Business Requirements is a FIXED-LENGTH ALPHANUMERIC CHARACTER SIZE 10 , which a FIXED STRING data type since the DiscountCode will always be the length of 10 . Thus, resulting in the Data Type CHAR (10) , with the NOT NULL constraint since the DiscountCode value is required column based on the Normalized Logical & EER Models . c. DiscountCodeDescription (Non-Key) Column – Also, it makes sense to derive the DBMSDataType & Constraint List for the NON-KEY column DiscountCodeDescription . The instances examples shown in the tabular listing for DiscountCodeDescription shows an alphanumeric VARIABLE-LENGTH ALPHANUMERIC CHARACTER string , which aligns to DBMSDataType VARCHAR2 (X) . But what is the size of X? If you look at the largest string value, and add a little room for growth, you can determine the value of X . In this case, the largest string is DiscountCodeDescription is AAA Membership Discount – 25% off base rate plus 10% donated to breast cancer research , which holds 86 characters including spaces . Thus, we can choose the value for X= 150 to take into account future growth, resulting in the Data Type VARCHAR2 (150) . In addition, we include the NOT NULL constraint since the DiscountCodeDescription value is required column based on the Normalized Logical & EER Models . 7) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the DiscountID Primary Key Column : DiscountID NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY 8) Remember that the PRIMARY KEY Constraint also includes internally the NOT NULL Constraint , which you don’t need to specify it. 9) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the NON-KEY COLUMN DiscountCode : DiscountCode CHAR( 10 ) NOT NULL 10) Note that for non-primary key data types you WILL NEED TO INCLUDE NOT NUL or NULL constraints when it applies. 11) Below are the results of our analysis and derived DBMSDataType , size/range , and Constraint List for the NON-KEY COLUMN DiscountCodeDescription : DiscountCodeDescription VARCHAR2( 150 ) NOT NULL 12) Note that for non-primary key data types you WILL NEED TO INCLUDE NOT NUL or NULL constraints when it applies.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

87 PART 5 ( Requirement 5d-4.1 Go Do #5 ) – EXECUTE Requirement 5c-4.1 to Design the Data Types for ALL PRIMARY KEYS that HAVE NO Business Meaning using the 4 PRIMARY KEY RULES : 1. Requirement 5d-4.1 Go Do #5a – From Analysis of the Business Requirements and review of the Normalized Logical Model, we have identified the 4 Tables in this section whose PRIMARY KEY HAVE NO Business Meaning and you need to DECIDE on the IDENTITY DATA TYPES for the Primary Key of EACH OF THESE TABLES. ▪ Go Do #4a EXECUTION – For Each of the 4 out of 33 tables listed below, follow the theory, FOLLOW THE FLOWCHART and examples in this document to create the Primary keys for the following Tables whose PRIMARY KEYS HAVE NO Business Meaning and are IDENTITIY Data Types: 1) CUSTOMER Table CustomerID – the Customer ID has no business meaning since the table will be searched by Driver License Numbered so the primary key can be any number. Use IDENTITY data type for this primary key . Determine whether to use the default size of the selected data types 2) DISCOUNT Table DiscountID – the Discount ID has no business meaning since the business requirements provide a tabular listing of the Discount IDs they use and it states is a random number; thus, this primary key has no business meaning and can be any number. Use IDENTITY data type for this primary key . 3) EZPLUS Table EZPlusID – the EZPlus ID has no business meaning since the business requirements provide a tabular listing of the EZPlus IDs they use and it states is a random number; thus, this primary key has no business meaning and can be any number. Use IDENTITY data type for this primary key . 4) VEHICLE Table VehicleID – the Vehicle ID has no business meaning since the table will be searched by VIN Number so the primary key can be any number. Use IDENTITY data type for this primary key .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

88  CST4708 Class GO DO #5a – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  IMPORTANT – Don’t forget to apply DESIGN GUIDELINE DATA TYPE RULE #2 & Requirement 5d-4.20 (Check the Business Requirements for possible clues to Data Type & Constraints) since both have examples of many of the primary keys for the tables listed above  CST3604 Class GO DO #5a – Search & identify in the 33 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  IMPORTANT – Don’t forget to apply DESIGN GUIDELINE DATA TYPE RULE #2 & Requirement 5d-4.20 (Check the Business Requirements for possible clues to Data Type & Constraints) since both have examples of many of the primary keys for the tables listed above

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

89 2. Requirement 5d-4.1 Go Do #5b – EXECUTE SPECIAL CASE where the Primary Key number HAS NO business meaning, and the data type IS NOT an INTEGER NUMBER but a CHARACTER , STRING OF CHARACTERS , GUID (Global Unique Identifier) OR OTHER DATA TYPE . ▪ Requirement 5d-4.1 Go Do #5b EXECUTION – SPECIAL CASE when the Primary Key number HAS NO business meaning BUT NOT A NUMBER – As per previous discussion, the recommendation for primary key is an INTEGER NUMBER data type as per the PRIMARY KEY RULE #1 , nevertheless this is not set in stone, there are cases where CHAR or STRING OF CHARACTERS or a special unique identifier GUID DATA TYPE or others, are the best option. The following PRIMARY KEY & Table(s) have been identified as candidate for a GUID data type and a requirement for this project: For Each of the following 2 out of 33 tables listed below, follow the FLOWCHART, theory and examples in this document to create the Primary keys for the following Tables whose PRIMARY KEYS HAVE NO Business Meaning and are GUID Data Types: 1) EMPLOYEEUSERACCOUNT Table EmployeeUserAccountID – This Primary Key column will use a GUID or GLOBAL UNIQUE IDENTIFIER CODE that is guaranteed to be UNIQUE ! Thus, providing the Employee User Account with a UNIQUE GUID VALUE generated by the Front-End Application . Detail on what a GUID is, what it looks like, how it is stored in a DATABASE and is Data Type is listed in this table in Requirement 5d-4.23 . For now, do nothing here and when you get to this requirement derived the Data Type for this Primary Key there . 2) CUSTOMERUSERACCOUNT Table CustomerUserAccountID – This Primary Key column will use a GUID or GLOBAL UNIQUE IDENTIFIER CODE that is guaranteed to be UNIQUE ! Thus, providing the Customer User Account with a UNIQUE GUID VALUE in this case generated by the DBMS . NOTE THE DIFFERENCE HERE COMPARED TO THE EMPLOYEEUSERACCOUNT TABLE ABOVE , the CustomerUserAccountID GUID is generated by the DATABASE , while the EmployeeUserAccountID was generated by the Front-end Application! Detail on what a GUID is, what it looks like, how it is stored in a DATABASE and is Data Type is listed in this table in Requirement 5d-4.24 . For now, do nothing here and when you get to this requirement derive the Data Type for this Primary Key there .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

90  CST4708 Class GO DO #5b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO #5b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

91 PART 6 ( Requirement 5d-4.1 Go Do #6 ) – EXECUTE Requirement 5c-4.1 to Design the Data Types for PRIMARY KEYS that are COMPOSITE PRIMARY KEY (Primary key composed of one or more columns of a table) whether they HAVE or HAVE NO business meaning as instructed below: 1. Requirement 5d-4.1 Go Do #6 – EXECUTE SPECIAL CASE where Primary Key is a Composite key . A Composite key is a Primary key composed of one or more columns of a table. They are usually found in an Associative Table or child table of several parents. The Primary Key to such a child table is composed of all the Foreign Keys of the Parent Tables. The Composite Primary Key is a combination of Foreign Keys whose PARENT PRIMARY KEYS HAVE business meaning or HAVE NO business meaning and in this case is does not matter since the decision on datatype has already been done when you decided on the DBMSDataType & Constraint of the Parent Tables primary key . All you need to keep in mind is that Foreign Keys CANNOT be IDENTITY so in the Composite Key, remove the keyword IDENTITY. In our Normalized Logical Model, two tables are Associative Tables with Composite Primary Keys : CUSTOMER_CREDITCARD table & TRANSPORT table. Below pictorial diagrams highlight these two associative tables and their parents from the Normalized Logical Model:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

92 1) The CUSTOMER_CREDITCARD table is an associative table that stores the UNITQUE IDENTIFIER of what CREDITCARD belongs to what CUSTOMER .. a. This table Primary Key is a Composite Primary Key composed of two columns: 1) a foreign key CreditCardNumber and 2) a foreign key CreditCardID which together the two columns become the Composite Primary Key of this CUSTOMER_CREDITCARD table b. Note composite keys are underlined . c. Also note that individually both CreditCardNumber and CreditCardID are foreign keys , but the foreign key part is not shown in the Logical Table , just the underlined on each column indicating each column is part of the Composite Primary Key of the table .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

93 2) The TRANSPORT table is an associative table that stores the UNITQUE IDENTIFIER of what Employee will TRANSPORT which VEHICLE to which RENTAL AGENCY . a. This table Primary Key is a Composite Primary Key composed of three columns: 1) a foreign key EmployeeID , 2) a foreign key VehicleID and 3) a foreign key PickUpRentalAgencyID which together all three columns become the Composite Primary Key of this TRANSPORT table. b. Note composite keys are underlined . c. Also note that individually all three columns EmployeeID , VehicleID and PickUpRentalAgencyID are foreign keys , but each foreign key part is not shown in Logical Table , just the underlined on each column indicating that each column is part of the Composite Primary Key of the table .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

94 ▪ Requirement 5d-4.1 Go Do #6 EXECUTION – SPECIAL CASE where Primary Key is a Composite Primary key . From Analysis of the Business Requirements and review of the Normalized Logical Model , we have identified the following Associative Tables that have COMPOSITE KEYS thus data types for these composite keys have already been decided when the Parent tables data types was decided. Each of the following 2 out of 33 tables listed below contain COMPOSITE KEYS made up of the Primary Keys of the Parent Tables . You need to determine the data types for these two Associative Tables : 1) CUSTOMER_CREDITCARD Table CreditCardNumber & CustomerID Composite Primary key – This CUSTOMER_CREDITCARD table COMPOSITE PRIMARY KEY is composed of two FOREIGN KEY columns in this table: CreditCardNumber & CustomerID . The datatype for the first CreditCardNumber foreign key column was already decided by the PARENT CREDITCARD Table CreditCardNumber primary key . And the second datatype for CustomerID foreign key column was also already decided by the PARENT CUSTOMER Table CustomerID primary key . Therefore, for this Associative Child Table CUSTOMER_CREDITCARD Composite Primary Key , the rule is COPY/PASTE THE DBMSDataType & CONSTRAINT LIST of EACH of the PARENT TABLES PRIMARY KEYS to the ASSOCIATIVE CHILD TABLE FOREIGN KEYS . NEVERTHELESS, IF ONE OF THE PARENTS HAPPENS TO BE AN IDENTITY DO NOT INCLUDE THE IDENTITY KEYWORD! A FOREIGN KEY CANNOT BE AN IDENTITY! Below is an example for the CUSTOMER_CREDITCARD Table Composite Key Data Type : CST4708 Class Use This Exampl e : o First , we identify the DBMSDataType & CONSTRAINT LIST of the CREDITCARD PARENT TABLE PRIMARY KEY CreditCardNumber and second , the DBMSDataType & CONSTRAINT LIST of the CUSTOMER PARENT TABLE PRIMARY KEY CustomerID since these two PRIMARY KEYS will determine the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY CreditCardNumber and CustomerID which make up the COMPOSITE PRIMARY KEY in the CUSTOMER_CEDITCARD CHILD ASSOCIATIVE TABLE . Below is the DBMSDataType & CONSTRAINT LIST of these two PARENT TABLES : Example in MS SQL Server of CREDITCARD & CUSTOMER Parent Tables Primary Keys CreditCardNumber & CustomerID DBMSDataType & CONSTRAINT LIST: CreditCardNumber VARCHAR(16) PRIMARY KEY CustomerID INT IDENTITY PRIMARY KEY  Note that we covered these examples in previous discussions.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

95 o Now , we derive the DBMSDataType & CONSTRAINT LIST for the CUSTOMER_CREDITCARD CHILD TABLE COMPOSITE KEY CreditCardNumber and CustomerID . NOTE that the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY CreditCardNumber and CustomerID is a COPY/PASTE of the PARENT TABLES PRIMARY KEYS WITHOUT THE KEYWORD IDENTITY SINCE A FOREIGN KEY CANNOT BE AN IDENTITY! Example in MS SQL Server of CUSTOMER_CREDITCARD Table Composite Key data type: CreditCardNumber VARCHAR(16) PRIMARY KEY CustomerID INT PRIMARY KEY  Note that in this example, the first composite foreign keys CreditCardNumber is assumed to match its parents Primary Keys DATA TYPE & VALUE since relationship rule states “ the VALUE & DATA TYPE of a foreign key MUST MATCH the VALUE & DATATYPE of the PARENT TABLE Primary Key EXCEPT the Foreign Key DATA TYPE CANNOT CONTAIN THE IDENTITY KEYWORD of the Parent Primary Key ” .  Note that in this example, the second composite key foreign key CustomerID , is assumed to be an INT IDENTITY Primary Key datatype in the CUSTOMER Table or Parent , but in the CUSTOMER_CREDITCARD table CustomerID is a foreign key and is an INT data type without the IDENTITY part !  You CANNOT make the FOREIGN KEY CustomerID in the CUSTOMER_CREDITCARD table an IDENTITY datatype because then the VALUE of this column would be automatically added by the DBMS and WILL NEVER MATCH the PARENT CUSTOMER table’s PRIMARY KEY VALUE and that would be a disaster since the relationship will be wrong! Keep in mind that the VALUE & DATA TYPE of a FOREIGN KEY must MATCH the VALUE & DATA TYPE of the PARENT TABLE PRIMARY KEY BUT THE DATA TYPE OF THE FOREIGN KEY CANNOT HAVE THE KEYWORD IDENTITY IN ITS DATA TYPE ! o First , we identify the DBMSDataType & CONSTRAINT LIST of the CREDITCARD PARENT TABLE PRIMARY KEY CreditCardNumber and second , the DBMSDataType & CONSTRAINT LIST of the CUSTOMER PARENT TABLE PRIMARY KEY CustomerID since these two PRIMARY KEYS will determine the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY CreditCardNumber and CustomerID which make up the COMPOSITE PRIMARY KEY in the CUSTOMER_CEDITCARD CHILD ASSOCIATIVE TABLE . Below is the DBMSDataType & CONSTRAINT LIST of these two PARENT TABLES :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

96 CST3604 Class Use This Exampl e : Example in Oracle Server of CREDITCARD & CUSTOMER Parent Tables Primary Keys CreditCardNumber & CustomerID DBMSDataType & CONSTRAINT LIST: CreditCardNumber VARCHAR(16) PRIMARY KEY CustomerID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY  Note that we covered these examples in previous discussions. o Now , we derive the DBMSDataType & CONSTRAINT LIST for the CUSTOMER_CREDITCARD CHILD TABLE COMPOSITE KEY CreditCardNumber and CustomerID . NOTE that the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY CreditCardNumber and CustomerID is a COPY/PASTE of the PARENT TABLES PRIMARY KEYS WITHOUT THE KEYWORD IDENTITY SINCE A FOREIGN KEY CANNOT BE AN IDENTITY! Example in Oracle Server of CUSTOMER_CREDITCARD Table Composite Key data type: CreditCardNumber VARCHAR2(16) PRIMARY KEY CustomerID NUMBER(10) PRIMARY KEY  Note that in this example, the first composite foreign keys CreditCardNumber is assumed to match its parents Primary Keys DATA TYPE & VALUE since relationship rule states “ the VALUE & DATA TYPE of a foreign key MUST MATCH the VALUE & DATATYPE of the PARENT TABLE Primary Key EXCEPT the Foreign Key DATA TYPE CANNOT CONTAIN THE IDENTITY KEYWORD of the Parent Primary Key ” .  Note that in this example, the second composite key foreign key CustomerID , in this scenario is assumed to be an NUMBER(10) GENERATED ALWAYS AS IDENTITY Primary Key datatype in the CUSTOMER Table or Parent , but in the CUSTOMER_CREDITCARD table CustomerID is a foreign key and is an NUMBER(10) data type without the IDENTITY part !  You CANNOT also make the FOREIGN KEY CustomerID a GENERATED ALWAYS AS IDENTITY datatype in the CUSTOMER_CREDITCARD table because then it would be automatically added by the DBMS and WILL NEVER MATCH the PRIMARY KEY VALUE of the parent table Customer and that would be a disaster! Keep in mind that the VALUE & DATA TYPE of a FOREIGN KEY must MATCH the VALUE & DATA TYPE of the PARENT TABLE PRIMARY KEY BUT THE DATA TYPE OF THE FOREIGN KEY CANNOT HAVE THE KEYWORD IDENTITY IN ITS DATA TYPE !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

97 2) TRANSPORT Table EmployeeID , VehicleID & PickUpRentalAgencyID Composite Primary key – This TRANSPORT table COMPOSITE PRIMARY KEY is composed of three FOREIGN KEY columns in this table: EmployeeID , VehicleID & RentalAgencyID . The datatype for the first EmployeeID foreign key column was already decided by the PARENT EMPLOYEE Table EmployeeID primary key . And the datatype for the second VehicleID foreign key column was also already decided by the PARENT VEHICLE Table VehicleID primary key , and finally the datatype for the third PickUpRentalAgencyID foreign key column was also already decided by the PARENT RENTALAGENCY Table RentalAgencyID primary key , Therefore, for this Associative Child Table TRANSPORT Composite Primary Key , choose the datatype of the composite columns Parent Tables Primary keys in the relationship , IF ONE OF THE PARENTS HAPPENS TO BE AN IDENTITY DO NOT INCLUDE THE IDENTITY KEYWORD! A FOREIGN KEY CANNOT BE AN IDENTITY! Below is the example for the TRANSPORT Table Composite Key Data Type : CST4708 Class Use This Exampl e : o First , we identify the DBMSDataType & CONSTRAINT LIST of the EMPLOYEE, VEHICLE & RENTALAGENCY PARENT TABLEs PRIMARY KEYS EmployeeID, VehicleID & RentalAgencyID a since these three PRIMARY KEYS will determine the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY EmployeeID, VehicleID & RentalAgencyID which make up the COMPOSITE PRIMARY KEY in the TRANSPORT CHILD ASSOCIATIVE TABLE . Below is the DBMSDataType & CONSTRAINT LIST of these three PARENT TABLES : Example in MS SQL Server of EMPLOYEE, VEHICLE & RENTALAGENCY Parent Tables Primary Keys EmployeeID, VehicleID & RentalAgencyID DBMSDataType & CONSTRAINT LIST: EmployeeID SMALLINT PRIMARY KEY CHECK ( EmployeeID between 1 and 20000 ) VehicleID INT IDENTITY PRIMARY KEY RentalAgencyID SMALLINT PRIMARY KEY CHECK ( RentalAgencyID between 1 and 10000 )  Note that we covered these examples in previous discussions.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

98 o Now , we derive the DBMSDataType & CONSTRAINT LIST for the TRANSPORT CHILD TABLE COMPOSITE KEY EmployeeID, VehicleID and PickUPRentalAgencyID . NOTE that the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY EmployeeID, VehicleID and PickUPRentalAgencyID is a COPY/PASTE of the PARENT TABLES PRIMARY KEYS WITHOUT THE KEYWORD IDENTITY SINCE A FOREIGN KEY CANNOT BE AN IDENTITY! Example in MS SQL Server of TRANSPORT Table Composite Key data type: EmployeeID SMALLINT PRIMARY KEY CHECK ( EmployeeID between 1 and 20000 ) VehicleID INT PRIMARY KEY PickUpRentalAgencyID SMALLINT PRIMARY KEY CHECK ( RentalAgencyID between 1 and 10000 )  Note that in this example, the first & third composite foreign keys EmployeeID & RentalAgencyID are assumed to match their parents Primary Keys DATA TYPE & VALUE since relationship rule states “ the VALUE & DATA TYPE of a foreign key MUST MATCH the VALUE & DATATYPE of the PARENT TABLE Primary Key EXCEPT the Foreign Key DATA TYPE CANNOT CONTAIN THE IDENTITY KEYWORD of the Parent Primary Key ” .  On the other hand, the second composite key foreign key VehicleID , is assumed to be an INT IDENTITY Primary Key datatype in the VECHICLE Table or Parent , but in the TRANSPORT table VehicleID is a foreign key and is an INT data type without the IDENTITY part !  You CANNOT make the FOREIGN KEY VehicleID in the TRANSPORT table an IDENTITY datatype because then the VALUE of this column would be automatically added by the DBMS and WILL NEVER MATCH the PARENT CUSTOMER table’s PRIMARY KEY VALUE and that would be a disaster since the relationship will be wrong! Keep in mind that the VALUE & DATA TYPE of a FOREIGN KEY must MATCH the VALUE & DATA TYPE of the PARENT TABLE PRIMARY KEY BUT THE DATA TYPE OF THE FOREIGN KEY CANNOT HAVE THE KEYWORD IDENTITY IN ITS DATA TYPE !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

99 CST3604 Class Use This Exampl e : o First , we identify the DBMSDataType & CONSTRAINT LIST of the EMPLOYEE, VEHICLE & RENTALAGENCY PARENT TABLEs PRIMARY KEYS EmployeeID, VehicleID & RentalAgencyID a since these three PRIMARY KEYS will determine the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY EmployeeID, VehicleID & RentalAgencyID which make up the COMPOSITE PRIMARY KEY in the TRANSPORT CHILD ASSOCIATIVE TABLE . Below is the DBMSDataType & CONSTRAINT LIST of these three PARENT TABLES : Example in Oracle Server of EMPLOYEE, VEHICLE & RENTALAGENCY Parent Tables Primary Keys EmployeeID, VehicleID & RentalAgencyID DBMSDataType & CONSTRAINT LIST: EmployeeID NUMBER(5) PRIMARY KEY CHECK ( EmployeeID between 1 and 20000 ) VehicleID NUMBER(9) GENERATED ALWAYS AS IDENTITY PRIMARY KEY PickUpRentalAgencyID NUMBER(5) PRIMARY KEY CHECK ( RentalAgencyID between 1 and 10000 )  Note that we covered these examples in previous discussions. o Now , we derive the DBMSDataType & CONSTRAINT LIST for the TRANSPORT CHILD TABLE COMPOSITE KEY EmployeeID, VehicleID and PickUPRentalAgencyID . NOTE that the DBMSDataType & CONSTRAINT LIST of EACH FOREIGN KEY EmployeeID, VehicleID and PickUPRentalAgencyID is a COPY/PASTE of the PARENT TABLES PRIMARY KEYS WITHOUT THE KEYWORD IDENTITY SINCE A FOREIGN KEY CANNOT BE AN IDENTITY! Example in Oracle Server of TRANSPORT Table Composite Key data type: EmployeeID NUMBER(5) PRIMARY KEY CHECK ( EmployeeID between 1 and 20000 ) VehicleID NUMBER(9) PRIMARY KEY PickUpRentalAgencyID NUMBER(5) PRIMARY KEY CHECK ( RentalAgencyID between 1 and 10000 )

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

100  Note that in this example, the first & third composite foreign keys EmployeeID & PickUpRentalAgencyID are assumed to match their parents Primary Keys DATA TYPE & VALUE since relationship rule states “ the VALUE & DATA TYPE of a foreign key MUST MATCH the VALUE & DATATYPE of the PARENT TABLE Primary Key EXCEPT the Foreign Key DATA TYPE CANNOT CONTAIN THE IDENTITY KEYWORD of the Parent Primary Key ” .  On the other hand, the second composite key foreign key VehicleID , is assumed to be a NUMBER(9) IDENTITY Primary Key datatype in the VECHICLE Table or Parent , but in the TRANSPORT table VehicleID is a foreign key and is an NUMBER(9) data type without the IDENTITY part !  You CANNOT make the FOREIGN KEY VehicleID in the TRANSPORT table an IDENTITY datatype because then the VALUE of this column would be automatically added by the DBMS and WILL NEVER MATCH the PARENT CUSTOMER table’s PRIMARY KEY VALUE and that would be a disaster since the relationship will be wrong! Keep in mind that the VALUE & DATA TYPE of a FOREIGN KEY must MATCH the VALUE & DATA TYPE of the PARENT TABLE PRIMARY KEY BUT THE DATA TYPE OF THE FOREIGN KEY CANNOT HAVE THE KEYWORD IDENTITY IN ITS DATA TYPE !  CST4708 Class Requirement 5d-4.1 GO DO #6a – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class Requirement 5d-4.1 GO DO #6b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

101 PART 7 ( Requirement 5d-4.1 Go Do #7 ) – EXECUTE Requirement 5c-4.1 to Design the Data Types for PRIMARY KEYS that are SUB-TYPES PRIMARY KEYS of a SUPERTYPE/SUBTYPE STRUCTURE whether they HAVE or HAVE NO business meaning as instructed below: 1. Requirement 5d-4.1 Go Do #7 – EXECUTE SPECIAL CASE where we are deriving the on the DBMSDataType & Constraint for the Primary Key of a SUBTYPE CHILD of a SUPERTYPE/SUBTYPE STRUCTURE . The Rules for deriving the Primary Key for a SUBTYPE CHILD of a SUPERTYPE/SUBTYPE STRUCTURE is as follows: a) A SUBTYPE CHILD table Primary Key DBMSDataType & Constraint MUST MATCH the SUPERTYPE PARENT table Primary Key DBMSDataType & Constraint . b) If the SUPERTYPE PARENT Primary Key HAS BUSINESS MEANING , BOTH the SUPERTYPE PARENT TABLE & the SUBTYPE CHILD TABLE HAVE THE SAME Primary Key DBMSDataType & Constraint . c) If the SUPERTYPE PARENT Primary Key HAS NO BUSINESS MEANING , then the SUPERTYPE PARENT Primary Key is an IDENTITY . BOTH the SUPERTYPE PARENT TABLE & the SUBTYPE CHILD TABLE HAVE THE SAME Primary Key DBMSDataType & Constraint EXCEPT for the SUBTYPE CHILD REMOVE the Keyword IDENTITY since a FOREING KEY CANNOT BE AN IDENTITY . In our Normalized Logical Model, two tables are SUBTYPE CHILD TABLES part of a SUPERTYPE/SUBTYPE STRUCTURE , the RETAILCUSTOMER table & CORPORATECUSTOMER table.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

102 Below pictorial diagrams highlight these two SUBTYPE CHILD TABLES and their relationship to their SUPERTYPE PARENT TABLE in the Normalized Logical Model: 1) The SUBTYPE CHILD TABLES RETAILCUSTOMER & CORPORATECUSTOMER represent the only two types of customers in this business as per the business requirements which is a standard retail customer and a corporate customer : a. Note that in this Project #1 scenario, the SUPERTYPE PARENT Primary Key CustomerID HAS NO BUSINESS MEANING thus an IDENTITY . b. As per our rules, both RETAILCUSTOMER & CORPORATECUSTOMER SUBTYPE CHILD TABLES Primary Key CustomerID DBMSDataType & Constraint MUST BE IDENTICAL to the SUPERTYPE CUSTOMER PARENT Primary Key CustomerID WITHOUT THE KEYWORD IDENTITY ! c. See illustration below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

103 2) The SUBTYPE CHILD TABLES CAR , SUV , MINIVAN & CARGOVAN represent the four main types of vehicles in this business, in addition to other types of vehicles as per the business requirements. a. Note that in this Project #1 scenario, the SUPERTYPE PARENT Primary Key VehicleID HAS NO BUSINESS MEANING thus an IDENTITY . b. As per our rules, all four CAR , SUV , MINIVAN & CARGOVAN SUBTYPE CHILD TABLES Primary Key VehicleID DBMSDataType & Constraint MUST BE IDENTICAL to the SUPERTYPE VEHICLE PARENT TABLE Primary Key VehicleID WITHOUT THE KEYWORD IDENTITY ! c. See illustration below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

104 ▪ Requirement 5d-4.1 Go Do #7 EXECUTION – SPECIAL CASE where we need to derive the DBMSDataType & Constraint for the Primary Key of a SUBTYPE CHILD of a SUPERTYPE/SUBTYPE STRUCTURE . From Analysis of the Business Requirements and review of the Normalized Logical Model , we have identified the following 6 out of 33 tables listed below that are SUBTYPES of a SUPERTYPE/SUBTYPE STRUCTURE : 1) RETAILCUSTOMER Table CustomerID Primary key – This RETAILCUSTOMER table is a SUBTYPE CHILD TABLE part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the CUSTOMER TABLE . The PRIMARY KEY/FOREIGN KEY column in this SUBTYPE CHILD TABLE is CustomerID . Note that because of the SUPERTYPE/SUBTYPE STRUCTURE this column can be seen as BOTH a PRIMARY KEY and a FOREIGN KEY . Based on the rules, the DBMSDataType & Constraint for this SUBTYPE CHILD TABLE CustomerID column was already decided by the PARENT SUPERTYPE Table CUSTOMER , therefore, this SUBTYPE CHILD TABLE CustomerID DBMSDataType & Constraint MUST MATCH the PARENT SUPERTYPE Table CUSTOMER Primary Key CustomerID DBMSDataType & Constraint WITHOUT the keyword IDENTITY . Below we derive the DBMSDataType & Constraint for the SUPERTYPE CUSTOMER PARENT TABLE Primary Key CustomerID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE RETAILCUSTOMER Primary Key CustomerID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE CUSTOMER Primary Key CustomerID using MS SQL SERVER is shown below: Example in MS SQL Server of CUSTOMER SUPERTYPE Table Primary Key CustomerID DBMSDataType & CONSTRAINT LIST : CustomerID INT IDENTITY PRIMARY KEY  Note that covered this example earlier so I am not going through the details. ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE RETAILCUSTOMER Primary Key CustomerID using MS SQL SERVER is shown below: Example in MS SQL Server of RETAILCUSTOMER SUBTYPE Table Primary Key CustomerID DBMSDataType & Contraint List (CST4708 Class Use This Example) : CustomerID INT PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

105 CST3604lass Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE CUSTOMER Primary Key CustomerID using ORACLE SERVER is shown below: Example in Oracle Server of CUSTOMER SUPERTYPE Table Primary Key CustomerID DBMSDataType & CONSTRAINT LIST : CustomerID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY  Note that covered this example earlier so I am not going through the details. ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE RETAILCUSTOMER Primary Key CustomerID using ORACLE SERVER is shown below: Example in Oracle Server of RETAILCUSTOMER SUBTYPE Table Primary Key CustomerID DBMSDataType & Contraint List : CustomerID NUMBER(10) PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

106 2) CORPORATECUSTOMER Table CustomerID Primary key – This CORPPORATECUSTOMER table is a SUBTYPE CHILD TABLE part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the CUSTOMER TABLE . The PRIMARY KEY/FOREIGN KEY column in this SUBTYPE CHILD TABLE is CustomerID . Note that because of the SUPERTYPE/SUBTYPE STRUCTURE this column can be seen as BOTH a PRIMARY KEY and a FOREIGN KEY . Based on the rules, the DBMSDataType & Constraint for this SUBTYPE CHILD TABLE CustomerID column was already decided by the PARENT SUPERTYPE Table CUSTOMER , therefore, this SUBTYPE CHILD TABLE CustomerID DBMSDataType & Constraint MUST MATCH the PARENT SUPERTYPE Table CUSTOMER Primary Key CustomerID DBMSDataType & Constraint WITHOUT the keyword IDENTITY . Below we derive the DBMSDataType & Constraint for the SUPERTYPE CUSTOMER PARENT TABLE Primary Key CustomerID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CORPORATECUSTOMER Primary Key CustomerID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE CUSTOMER Primary Key CustomerID using MS SQL SERVER is shown below: Example in MS SQL Server of CUSTOMER SUPERTYPE Table Primary Key CustomerID DBMSDataType & CONSTRAINT LIST : CustomerID INT IDENTITY PRIMARY KEY  Note that covered this example earlier so I am not going through the details. ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CORPORATECUSTOMER Primary Key CustomerID using MS SQL SERVER is shown below: Example in MS SQL Server of CORPORATECUSTOMER SUBTYPE Table Primary Key CustomerID DBMSDataType & Contraint List : CustomerID INT PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

107 CST3604 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE CUSTOMER Primary Key CustomerID using ORACLE SERVER is shown below: Example in Oracle Server of CUSTOMER SUPERTYPE Table Primary Key CustomerID DBMSDataType & CONSTRAINT LIST : CustomerID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY  Note that covered this example earlier so I am not going through the details. ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CORPORATECUSTOMER Primary Key CustomerID using ORACLE SERVER is shown below: Example in Oracle Server of CORPORATECUSTOMER SUBTYPE Table Primary Key CustomerID DBMSDataType & Contraint List : CustomerID NUMBER(10) PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

108 3) CAR Table VehicleID Primary key – This CAR table is a SUBTYPE CHILD TABLE part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the VEHICLE TABLE . The PRIMARY KEY/FOREIGN KEY column in this SUBTYPE CHILD TABLE is VehicleID . Note that because of the SUPERTYPE/SUBTYPE STRUCTURE this column can be seen as BOTH a PRIMARY KEY and a FOREIGN KEY . Based on the rules, the DBMSDataType & Constraint for this SUBTYPE CHILD TABLE VehicleID column was already decided by the PARENT SUPERTYPE Table CUSTOMER , therefore, this SUBTYPE CHILD TABLE VehicleID DBMSDataType & Constraint MUST MATCH the PARENT SUPERTYPE Table CUSTOMER Primary Key VehicleID DBMSDataType & Constraint WITHOUT the keyword IDENTITY . Below we derive the DBMSDataType & Constraint for the SUPERTYPE VEHICLE PARENT TABLE Primary Key VehicleID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CAR Primary Key VehicleID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using MS SQL SERVER is shown below: Example in MS SQL Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID INT IDENTITY PRIMARY KEY  We chose an MS SQL SERVER INT DBMSDataType for VehicleID .  The logic here is that because the number of vehicles owned by the company is going to grow in the next 20 to 30 years , we want to make sure we don’t hit a limit. The MS SQL SERVER INT DBMSDataType has a MAX LIMIT of around 2.2 Billion which should be enough. You could also decide on BIG INT ! ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CAR Primary Key VehilceID using MS SQL SERVER is shown below: Example in MS SQL Server of CAR SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID INT PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

109 CST3604 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY  We chose an ORACLE SERVER NUMBER(10) DBMSDataType for VehicleID .  The logic here is that because the number of vehicles owned by the company is going to grow in the next 20 to 30 years , we want to make sure we don’t hit a limit. The ORACLE SERVER NUMBER(10) DBMSDataType has a MAX LIMIT of 9,999.999,999 around 9.9 Billion which should be enough. You could also decide on NUMBER with its 38 digit number but we decided on NUMBER(10) . ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CAR Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of CAR SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID NUMBER(10) PRIMARY KEY  Note that the DBMSDataType & Constraint are the same as the PARENT TABLE but WITHOUT the IDENTITY keyword . A FOREIGN KEY CANNOT BE AN IDENTITY !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

110 4) SUV Table VehicleID Primary key – We Will use the same process and logic for this SUV table, as we did with the CAR table since the SUV SUBTYPE CHILD TABLE is also part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the VEHICLE TABLE . Below we derive the DBMSDataType & Constraint for the SUPERTYPE VEHICLE PARENT TABLE Primary Key VehicleID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE SUV Primary Key VehicleID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using MS SQL SERVER is shown below: Example in MS SQL Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID INT IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE SUV Primary Key VehilceID using MS SQL SERVER is shown below: Example in MS SQL Server of SUV SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID INT PRIMARY KEY CST3604 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE SUV Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of SUV SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID NUMBER(10) PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

111 5) MINIVAN Table VehicleID Primary key – We Will use the same process and logic for this MINIVAN table, as we did with the CAR table since the MINIVAN SUBTYPE CHILD TABLE is also part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the VEHICLE TABLE . Below we derive the DBMSDataType & Constraint for the SUPERTYPE VEHICLE PARENT TABLE Primary Key VehicleID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE MINIVAN Primary Key VehicleID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using MS SQL SERVER is shown below: Example in MS SQL Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID INT IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE MINIVAN Primary Key VehilceID using MS SQL SERVER is shown below: Example in MS SQL Server of MINIVAN SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID INT PRIMARY KEY CST3604 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE MINIVAN Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of MINIVAN SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID NUMBER(10) PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

112 6) CARGOVAN Table VehicleID Primary key – We Will use the same process and logic for this CARGOVAN table, as we did with the CAR table since the CARGOVAN SUBTYPE CHILD TABLE is also part of a SUPERTYPE/SUBTYPE STRUCTURE whose SUPERTYPE PARENT is the VEHICLE TABLE . Below we derive the DBMSDataType & Constraint for the SUPERTYPE VEHICLE PARENT TABLE Primary Key VehicleID and then we derive the DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CARGOVAN Primary Key VehicleID : CST4708 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using MS SQL SERVER is shown below: Example in MS SQL Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID INT IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CARGOVAN Primary Key VehilceID using MS SQL SERVER is shown below: Example in MS SQL Server of CARGOVAN SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint : VehicleID INT PRIMARY KEY CST3604 Class Use This Exampl e : ‐ The DBMSDataType & Constraint for the SUPERTYPE PARENT TABLE VEHICLE Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of VEHICLE SUPERTYPE Table Primary Key VehicleID DBMSDataType & CONSTRAINT LIST : VehicleID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY ‐ The DBMSDataType & Constraint for the SUBTYPE CHILD TABLE CARGOVAN Primary Key VehicleID using ORACLE SERVER is shown below: Example in Oracle Server of CARGOVAN SUBTYPE Table Primary Key VehicleID DBMSDataType & Contraint List : VehicleID NUMBER(10) PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

113  CST4708 Class Requirement 5d-4.1 GO DO #7a – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class Requirement 5d-4.1 GO DO #7b – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

114 Summary & Explanation of Results of Executing Requirement #5d-4.1 to determine the Primary Key of all the table in scope for CST3604 & CST4708 ❑ In Requirement #5d-4.1 , you were asked to derive the Datatype , Constraints and METADATA for the PRIMARY KEY column for each of the Logical Tables of the Normalized Logical Model in scope of CST3604 & CST4708 and enter the information into each of the Data Dictionary Tables . FOR CST3604 CLASS ONLY ❑ Executing Requirement #5d-4.1 , should have resulted in populating the PRIMARY KEY column METADATA of the Data Dictionary Tables for following 13 Logical Tables of the PILOT Normalized Logical Model :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

115 Project #1 Primary Keys that HAVE BUSINESS MEANING and Follow Best Practice of NUMERIC INTEGER ❑ Based on Requirement #5d-4.1 , the following Logical Tables Primary Keys HAVE BUSINESS MEANING and are seen by the business, used in reports, conversations, UIs etc. This also means their data type is a NUMERIC INTEGER : ▪ CREDITCARDMERCHANT Table MerchantCode – The business requirements provide examples of the data used for this column which helps decide on this data type. ▪ COMPANY Table CompanyID – In Requirement #5d-4.1 PART 2 , there is an example of how to derive the Datatype & Constraint to this Primary Key . ▪ USSTATE Table StateID – There is already a requirement to determine the datatype & constraint for ALL the columns of the USState Table . This would be Requirement #5d-4.21 . ▪ COUNTRY Table CountryID – There is already a requirement to determine the datatype & constraint for ALL the columns of the Country Table . This would be Requirement #5d-4.22 . Primary Keys that HAVE BUSINESS MEANING but a VARIABLE-LENGTH CHARACTER STRING ❑ Based on Requirement #5d-4.1 , the following Logical Tables Primary Keys HAVE BUSINESS MEANING and are seen by the business, used in reports, conversations, UIs etc. But their data type is NOT a NUMERIC INTEGER but a Variable Character String of a specific maximum size : ▪ DRIVERLICENSE Table DriverLicenseNumber – The value to this data type is naturally already unique. The business requirements provide information to help you decide on this data type. You can also look at your own Driver’s License Number, but this data type should be a global scope. ▪ CREDITCARDNUMBER Table CreditCardNumber – Requirement #5d-4.1 indicated in GO DO #3b that this data type should be a variable-length string of size 16 , therefore answer given.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

116 Primary Keys that HAVE NO BUSINESS MEANING thus are IDENTITY ADDED BY THE DBMS ❑ Based on Requirement #5d-4.1 PART 4 GO DO #4 & 5 GO DO #5 , contains examples/answers for Primary Keys that HAVE NO BUSINESS MEANING , which mean these data types are IDENTITY INTEGER NUMBER which is automatically generated & inserted by the DBMS and inserted to the Primary Key Column: ▪ CUSTOMER Table CustomerID – In be Requirement #5d-4.1 PART 4 , actual examples/answers for determining the IDENTITY Primary keys of the CUSTOMER Table Primary Key . IMPORTANT! Note that this CUSTOMER Table is also the SUPERTYPE to a SUPERTYPE/SUBTYPE STRUCTURE Composed of CUSTOMER TABLE , RETAILCUSTOMER TABLE & CORPORATECUSTOMER TABLE . ▪ DISCOUNT Table DiscountID – In be Requirement #5d-4.1 PART 4 , also contain actual examples/answers for determining the IDENTITY Primary keys of the DISCOUNT Table Primary Key . ▪ EZPLUS Table EZPlusID – The business requirements provide examples of this random integer number which is automatically generated & inserted by the DBMS and inserted to the Primary Key Column . Also, Requirement #5d-4.3 , is an unrelated requirement that its focus is on FORIENG-KEY Scenario #2 – Determining the Datatype & Constraint to a FOREIGN KEY COLUMN WHOSE PARENT TABLE PRIMARY KEY IS AN IDENTITY, nevertheless, to showcase this foreign key datatype & constraint, it uses the EZPlus Table , therefore example of this IDENTITY Primary keys of the EZPlus Table is found there . Primary Keys that HAVE NO BUSINESS MEANING but are alphanumeric GLOBAL UNIQUE IDENTIFIER (GUID) ❑ Based on Requirement #5d-4.1 PART 5 GO DO #5b , contains examples/answers for Primary Keys that HAVE NO BUSINESS MEANING , and are alphanumeric GLOBAL UNIQUE IDENTIFIER (GUID) which are either automatically generated by the FRONT-END APPLICATION or by the DBMS . In the Pilot Logical Model scope, the GUID is automatically generated by the DBMS : ▪ CUSTOMERUSERACCOUNT Table CustomerUserAccountID – Requirement #5d-4.1 PART 5 GO DO #5b , directs you to Requirement #5d-4.1 for examples/answers for determining this GUID data type.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

117 Primary Keys that are a combination of multiple columns or COMPOSITE PRIMARY KEY (Primary Key can be a combination of Foreign Keys Whose Parent Primary Keys HAVE or DOES NOT HAVE Business Meaning) ❑ Based on Requirement #5d-4.1 PART 6 GO DO #6 , contains examples/answers for the following COMPOSITE PRIMARY KEY : ▪ CUSTOMER_CREDITCARD Table CreditCardNumber & CustomerID Composite Primary key – In be Requirement #5d-4.1 PART 6 GO DO #6 , actual examples/answers for determining the COMPOSITE Primary key of the CUSTOMER_CREDITCARD Table are provided. Primary Keys that are SUBTYPES of a SUPERTYPE/SUBTYPE STRUCTURE ❑ Based on Requirement #5d-4.1 PART 7 GO DO #7 , contains examples/answers for the following SUBTYPE TABLES PRIMARY KEYS : ▪ RETAILCUSTOMER Table CustomerID – In be Requirement #5d-4.1 PART 7 , clearly show that the Primary Key to a SUBTYPE Table is the same as the Primary Key to the SUPERTYPE PARENT Table , which in this case is CustomerID . See this section for examples/answers. ▪ CORPORATECUSTOMER Table CustomerID – In be Requirement #5d-4.1 PART 7 , clearly show that the Primary Key to a SUBTYPE Table is the same as the Primary Key to the SUPERTYPE PARENT Table , which in this case is CustomerID . See this section for examples/answers .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

118 FOR CST4708 CLASS ONLY ❑ Executing Requirement #5d-4.1 , should have resulted in populating the PRIMARY KEY column METADATA of the Data Dictionary Tables for following 4 Logical Tables of the PROOF-OF-CONCEPT Normalized Logical Model :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

119 Primary Keys that HAVE BUSINESS MEANING ❑ Based on Requirement #5d-4.1 , the following Logical Tables Primary Keys HAVE BUSINESS MEANING and are seen by the business, used in reports, conversations, UIs etc. This also means their data type is a NUMERIC INTEGER : ▪ CREDITCARDMERCHANT Table MerchantCode – The business requirements provide examples of the data used for this column which helps decide on this data type. ▪ USSTATE Table StateID – There is already a requirement to determine the datatype & constraint for ALL the columns of the USState Table . This would be Requirement #5d-4.21 . ▪ COUNTRY Table CountryID – There is already a requirement to determine the datatype & constraint for ALL the columns of the Country Table . This would be Requirement #5d-4.22 . ❑ Based on Requirement #5d-4.1 , the following Logical Tables Primary Keys HAVE BUSINESS MEANING and are seen by the business, used in reports, conversations, UIs etc. But their data type is NOT a NUMERIC INTEGER but a Variable Character String of a specific maximum size : ▪ CREDITCARDNUMBER Table CreditCardNumber – Requirement #5d-4.1 indicated in GO DO #3b that this data type should be a variable-length string of size 16 , therefore answer given.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

120 7. Requirement #5d-4.2 through Requirement #5d-4.5 – In APPENDIX C, DESIGN GUIDELINE DATA TYPE RULE #4 – states “ NEXT FOCUS ON DESIGNING THE DBMSDATATYPE & CONSTRATINS FOR THE FOREING KEY NON-KEY COLUMNS OF A DICTIONARY TABLE” :  The FLOWCHART below walks you through the STEPS to deriving the DBMSDataType & Constraints for ALL the PRIMARY KEYS in REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.5 : Detailed Flow Chart for Derriving the DBMSDataType & Constraint for the FOREIGN KEY Columns of a Table as per Requirements 5d-4.2 through Requirements 5d-4.5

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

121 COLUMN/TABLE REQUIREMENT Requirement 5d-4.2: Foreign Key/Parent Primary Key Relationships FOREING KEY DATA TYPE RULE #1 Scenario #1 – Determining the Datatype & Constraint to a FOREIGN KEY whose PARENT TABLE PRIMARY KEY IS NOT AN IDENTITY , GUID or other : ▪ FOREIGN KEY RULE #1 – In a Relationships Between a PARENT & CHILD Table, the CHILD TABLE Foreign Key Column DATA TYPE & VALUE MUST MATCH the PARENT TABLE Primary Key DATA TYPE & VALUE without the constraint keyword PRIMARY KEY 1. Go Do #1 – In this scenario #1 , we will show two examples of determining the DATA TYPE for a Foreign Key when the Primary Key IS NOT an IDENTITY , GUID or other. 2. DATA TYPE RULE #1 states that in a Relationships Between Tables, where Primary Key IS NOT an IDENTITY , a CHILD TABLE Foreign Key Column DATA TYPE & VALUE MUST MATCH the PARENT TABLE Primary Key DATA TYPE & VALUE without the constraint keyword PRIMARY KEY . The following two examples will illustrate this Foreign key rule for determining a foreign key ’ s data type & constraint: 1) Example scenario #1a is the relationship between the Primary key DriverLicenseNumber in the DRIVERLICENSE table and its Foreign Key in the CUSTOMER table DriverLicenseNumber :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

122 ▪ Execute this requirement on ALL Foreign/Primary Key RELATIONSHIPS whose PARENT Primary Key ARE NOT IDENTITIES in your Normalize Logical Model scope. o We assume the following for the PARENT DRIVERLICENSE table Primary Key DriverLicenseNumber : - The DATA TYPE for the Primary key DriverLicenseNumber in the DRIVERLICENSE table is the following NON - IDENTITY data type : Example in MS SQL Server of DRIVERLICENSE Table Primary Key DriverLicenseNumber data type (CST4708 Class Use This Example) : DriverLicenseNumber VARCHAR(25) PRIMARY KEY Example in Oracle Server of DRIVERLICENSE Table Primary Key DriverLicenseNumber data type (CST3604 Class Use This Example) : DriverLicenseNumber VARCHAR2(25) PRIMARY KEY o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULE #1 : - The DATA TYPE for the Foreign key DriverLicenseNumber in the CHILD CUSTOMER table is the following NON - IDENTITY data type : Example in MS SQL Server of CUSTOMER Table Foreign Key DriverLicenseNumber data type (CST4708 Class Use This Example) : DriverLicenseNumber VARCHAR(25) UNIQUE NOT NULL Example in Oracle Server of CUSTOMER Table Foreign Key DriverLicenseNumber data type (CST3604 Class Use This Example) : DriverLicenseNumber VARCHAR2(25) UNIQUE NOT NULL

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

123 2) Example scenario #1b is the relationship between the Primary key CompanyID in the COMPANY table and its Foreign Key in the CORPORATECUSTOMER table CompanyID : o We assume the following for the PARENT COMPANY table Primary Key CompanyID : - The DATA TYPE for the Primary key CompanyID in the COMPANY table is the following NON - IDENTITY data type : Example in MS SQL Server of COMPANY Table Primary Key CompanyID data type (CST4708 Class Use This Example) : CompanyID SMALLINT CHECK ( CompanyID between 1 and 20000 ) PRIMARY KEY Example in Oracle Server of COMPANY Table Primary Key DriverLicenseNumber data type (CST3604 Class Use This Example) : CompanyID NUMBER(5) CHECK ( CompanyID between 1 and 20000 ) PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

124 o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULE #1 : - The DATA TYPE for the Foreign key CompanyID in the CHILD table CORPORATECUSTOMER is the following NON - IDENTITY data type : Example in MS SQL Server of CORPORATECUSTOMER Table Foreign Key CompanyID data type (CST4708 Class Use This Example) : CompanyID SMALLINT CHECK ( CompanyID between 1 and 20000 ) NOT NULL Example in Oracle Server of CORPORATECUSTOMER Table Foreign Key CompanyID data type (CST3604 Class Use This Example) : CompanyID NUMBER(5) CHECK ( CompanyID between 1 and 20000 ) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

125 Requirement 5d-4.3: Foreign Key/Parent Primary Key Relationships FOREING KEY DATA TYPE RULE #2 Scenario #2 – Determining the Datatype & Constraint to a FOREIGN KEY PARENT TABLE PRIMARY KEY IS AN IDENTITY : ▪ FOREIGN KEY RULE #2 – In a Relationships Between a PARENT & CHILD Table, the CHILD TABLE Foreign Key Column DATA TYPE & VALUE MUST MATCH the PARENT TABLE Primary Key DATA TYPE & VALUE, BUT IF THE PARENT TABLE Primary Key IS AN IDENTITY THE CHILD TABLE Foreign Key CANNOT BE AN IDENTITY . Both the IDENITY keyword and the constraint keyword PRIMARY KEY cannot be used! ▪ Go Do #1 – In this scenario #2 , we will show two examples of determining the DATA TYPE for a Foreign Key when the Primary Key IS an IDENTITY . ▪ DATA TYPE RULE #2 states that In a Relationships Between Tables, a CHILD TABLE Foreign Key Column DATA TYPE & CONTRAINT VALUES MUST MATCH the PARENT TABLE Primary Key DATA TYPE & VALUE, BUT IF THE PARENT TABLE Primary Key IS AN IDENTITY THE CHILD TABLE Foreign Key MUST MATCH CANNOT BE AN IDENTITY . Both the IDENITY keyword and the constraint keyword PRIMARY KEY cannot used with the Foreign Key Datatype and Constraint . A Foreign Key CANNOT BE IDENTITY! Let ’ s look at two examples below, to fully get this rule and concept: 1) Example scenario #2a is the relationship between the Primary key DiscountID in the DISCOUNT table and its Foreign Key in the RETAILCUSTOMER table DiscountID :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

126 ▪ Execute this requirement on ALL Foreign/Primary Key RELATIONSHIPS whose PARENT Primary Key ARE IDENTITIES in your Normalize Logical Model scope. o We assume the following for the PARENT DISCOUNT table Primary Key DiscountID : - The DATA TYPE for the Primary key DiscountID in the DISCOUNT table is the following IDENTITY data type : Example in MS SQL Server of DISCOUNT Table Primary Key DiscountID data type (CST4708 Class Use This Example) : DiscountID INT IDENTITY PRIMARY KEY Example in Oracle Server of DISCOUNT Table Primary Key DiscountID data type (CST3604 Class Use This Example) : DiscountID NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULE #2 : - First, based on the Business Requirements and the Normalized Logical Model , the Foreign key DiscountID in the CHILD RETAILCUSTOMER table is OPTIONAL! This means that not all Retail Customers are members of the EZPLus program! This optional value needs to be represented in the CHILD RETAILCUSTOMER table DATA TYPE definition . - Finally, the DATA TYPE for the Foreign key DiscountID in the CHILD RETAILCUSTOMER table is the following NON - IDENTITY data type : Example in MS SQL Server of RETAILCUSTOMER Table Foreign Key DiscountID data type (CST4708 Class Use This Example) : DiscountID INT NULL Example in Oracle Server of RETAILCUSTOMER Table Foreign Key DiscountID data type (CST3604 Class Use This Example) : DiscountID NUMBER NULL

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

127 2) Example scenario #2b is the relationship between the Primary key EZPlusID in the EZPLUS table and its Foreign Key in the RETAILCUSTOMER table EZPlusID : o We assume the following for the PARENT EZPLUS table Primary Key EZPlusID : - The DATA TYPE for the Primary key EZPlusID in the EZPLUS table is the following IDENTITY data type : Example in MS SQL Server of EZPLUS Table Primary Key EZPlusID data type (CST4708 Class Use This Example) : EZPlusID INT IDENTITY PRIMARY KEY Example in Oracle Server of EZPLUS Table Primary Key EZPlusID data type (CST3604 Class Use This Example) : EZPlusID NUMBER(10) GENERATED ALWAYS AS IDENTITY PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

128 o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULE #2 : - First, based on the Business Requirements and the Normalized Logical Model , the Foreign key DiscountID in the CHILD RETAILCUSTOMER table is OPTIONAL! This means that not all Retail Customers are members of the EZPLus program! This optional value needs to be represented in the CHILD RETAILCUSTOMER table DATA TYPE definition . - Finally, the complete DATA TYPE definition for the Foreign key EZPlusID in the CHILD RETAILCUSTOMER table is the following NON - IDENTITY data type : Example in MS SQL Server of EZPLUS Table Primary Key EZPlusID data type (CST4708 Class Use This Example) : EZPlusID INT NULL Example in Oracle Server of EZPLUS Table Primary Key EZPlusID data type (CST3604 Class Use This Example) : EZPlusID NUMBER(10) NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

129 Requirement 5d-4.4: Foreign Key/Parent Primary Key Relationships FOREING KEY DATA TYPE RULE #3 Scenario #3 – Determining the Datatype & Constraint to a FOREIGN KEY DATA TYPE whose PARENT TABLE PRIMARY KEY IS NOT A GUID Generated by the Database but Primary Key Column DOES STORE a GUI Created & Generated by from the Front- End Application : ▪ FOREIGN KEY RULE #3 – In a Relationships Between a PARENT & CHILD Table where the PARENT Table Primary Key STORES a GUID VALUE CREATED & GENERATED by the Front-end Application , the CHILD TABLE Foreign Key DATA TYPE & VALUE MUST MATCH the PARENT TABLE 1. Go Do – In this scenario #3 , we will show two examples of determining the DATA TYPE for a Foreign Key when the Primary Key STORES a GUID Created & Generated by the FRONT-END APPLICATION . 2. In the EMPLOYEEUSERACCOUNT table , the primary key EmployeeUserAccountID is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the Front-End Application written in C#, Java or other language (Optionally, for more details, you can read Requirement #5e ). NOTE that this GUID Primary Key COULD HAVE or NOT HAVE Business Meaning. 3. The point here is that the EmployeeUserAccountID PRIMARY KEY in the EMPLOYEEUSERACCOUNT table , is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the Front-End Application . This special string looks as follows: C# GUID: {3F2504E0-4F89-11D3-9A0C-0305E82C3301} (38 characters) or simpler version 3F2504E0-4F89-11D3-9A0C-0305E82C3301 (36 characters) . Java GUID: C395BF6C38914BCFA0A8145DDC35C04E (32 characters) . 4. We will cover GUID in detail in requirements Requirement 5c-4.23 , but in this scenario #3 , we will show the example of determining the DATA TYPE for a Foreign Key when the Parent Primary key is a targeted to store a GUID . 5. DATA TYPE RULE #3 states that in a Relationships Between a CHILD table and its parent PRIMARY KEY Table, to determine the FOREIGN KEY of the Child table, if the Parent Table Primary Key STORES a GUID Created & Generated by the FRONT-END APPLICATION and the PARENT TABLE PRIMARY KEY uses a special DBMS Specific Datatype , then the CHILD TABLE Foreign Key Column DATA TYPE & CONSTRAINT VALUES MUST MATCH or be the same special DBMS Specific Datatype as PARENT TABLE Primary Key DATA TYPE & VALUE without the constraint keyword PRIMARY KEY .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

130 Primary Key DATA TYPE & VALUE without the constraint keyword PRIMARY KEY ▪ Execute this requirement on ALL Foreign/Primary Key RELATIONSHIPS whose PARENT Primary Key STORE A GUID GENERATED by the FRONT-END APPLICATION in your Normalize Logical Model scope. ▪ Note that Database Management Systems (DBMS) usually have a special Datatype to Store GUID (See the DBMS Data Type Table for this datatype). 1) Example scenario #3 is the relationship between the Primary key EmployeeUserAccountID in the EMPLOYEE table and its Foreign Key in the CUSTOMER table EmployeeUserAccountID : o We assume the following for the PARENT EMPLOYEE table Primary Key EmployeeUserAccountID : - The DATA TYPE for the Primary key EmployeeUserAccountID in the EMPLOYEE table is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the Front-End Application . Note that each DBMS has a special datatype to store a GUID . This GUID PRIMARY KEY has the following data type : Example in MS SQL Server for EMPLOYEEUSERACCOUNT Table EmployeeUserAccountID primary key columns (CST4708 Class Use This Example) : EmployeeUserAccountID UNIQUEIDENTIFIER PRIMARY KEY Example in Oracle Server for EMPLOYEEUSERACCOUNT Table EmployeeUserAccountID primary key columns (CST3604 Class Use This Example) : EmployeeUserAccountID RAW(16) PRIMARY KEY

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

131 o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULE #3 stating the values must match except don’t use Primary Key keyword : - The DATA TYPE for the Foreign key EmployeeUserAccountID in the CHILD EMPLOYEE table is the following data type : Example in MS SQL Server for EMPLOYEE Table EmployeeUserAccountID FOREING KEY column (CST4708 Class Use This Example) : EmployeeUserAccountID UNIQUEIDENTIFIER NOT NULL Example in Oracle Server for EMPLOYEE Table EmployeeUserAccountID primary key columns (CST3604 Class Use This Example) : EmployeeUserAccountID RAW(16) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

132 Requirement 5d-4.5: Foreign Key/Parent Primary Key Relationships FOREING KEY DATA TYPE RULE #4 Scenario #4 – Determining the Datatype & Constraint to a FOREIGN KEY whose PARENT TABLE PRIMARY KEY IS A GUID Created & Generated by the BACK-END DATABASE : ▪ FOREIGN KEY RULE #4 – In a Relationships Between Parent & Child Table, where the Primary Key of the Parent Table is a GUID VALUE IS CREATED & GENERATED by the DATABASE , the CHILD TABLE Foreign Key DATA TYPE & VALUE MUST MATCH the PARENT TABLE Primary Key DATA TYPE & VALUE without the GUID Generating Function & Mechanism and without the constraint keyword PRIMARY KEY ! ▪ Go Do – In this scenario #4 , we will show two examples of determining the DATA TYPE for a Foreign Key when the Primary Key IS a GUID Generated by the DATABASE . ▪ In the CUSTOMERUSERACCOUNT table , the primary key CustomerUserAccountID is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the DATABASE (Optionally, for more details, you can read Requirement #5e ). NOTE that this GUID Primary Key COULD HAVE or NOT HAVE Business Meaning. ▪ The point here is that the CustomerUserAccountID PRIMARY KEY in the CUSTOMERUSERACCOUNT table , is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the DATABASE ITSELF . This special string looks as follows: MS SQL: 3F2504E0-4F89-11D3-9A0C-0305E82C3301 (36 characters) . ORACLE: C395BF6C38914BCFA0A8145DDC35C04E (32 characters) . ▪ DATA TYPE RULE #4 states that In a Relationships Between Tables, and the THE PARENT TABLE Primary Key STORES a GUID Created & Generated BY THE BACKEND DATABASE, the CHILD TABLE Foreign Key Column DATA TYPE & CONSTRAINT VALUES MUST MATCH the PARENT TABLE Primary Key DATA TYPE & CONSTRAINT VALUES WITHOUT The GUID GENERATING FUNCTIONS AND MECHANISM IN ADDITION TO THE keyword PRIMARY KEY which cannot be used in the Foreign Key .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

133 ▪ Execute this requirement on ALL Foreign/Primary Key RELATIONSHIPS whose Primary Key ARE GUID GENERATED BY THE DATABASE in your Normalize Logical Model scope. 1) Example scenario #4 is the relationship between the Primary key CustomerUserAccountID in the CUSTOMERUSERACCOUNT table and its Foreign Key in the CUSTOMER table CustomerUserAccountID : o We assume the following for the PARENT CUSTOMERUSERACCOUNT table Primary Key CustomerUserAccountID : - The DATA TYPE for the Primary key CustomerUserAccountID Column in the CUSTOMERUSERACCOUNT table , stores a GUID UNIQUE IDENTIFER ALPHANUMERIC STRING GENERATED BY THE DATABASE. Again, here is what it looks like for MS SQL Server & Oracle Server : MS SQL: 3F2504E0-4F89-11D3-9A0C-0305E82C3301 (36 characters) . ORACLE: C395BF6C38914BCFA0A8145DDC35C04E (32 characters) .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

134 - The data type for this PRIMARY KEY column is shown below: Example in MS SQL Server for CUSTOMERUSERACCOUNT Table CustomerUserAccountID primary key columns (CST4708 Class Use This Example) : CustomerUserAccountID UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY Example in Oracle Server for CUSTOMERUSERACCOUNT Table CustomerUserAccountID primary key columns (CST3604 Class Use This Example) : CustomerUserAccountID RAW(16) DEFAULT SYS_GUID() PRIMARY KEY o Therefore, based on Foreign Key/Parent Primary Key Relationships DATA TYPE RULES which states Foreign Key MUST MATCH THE DATA TYPE & VALUE EXCEPT YOU CANNOT INCLUDE THE GUID GENERATING MECHANISM OF THE PARENT PRIMARY KEY IN ADDITION YOU CANNOT USE THE PRIMARY KEY keyword : - First, based on the Business Requirements and the Normalized Logical Model , the Foreign key CustomerUserAccountID in the CHILD CUSTOMER table is OPTIONAL! This means that not all Customers may have a Customer User Account ID! This optional value needs to be represented in the CHILD CUSTOMER table DATA TYPE definition . - Finally, the DATA TYPE for the Foreign key CustomerUserAccountID in the CHILD CUSTOMER table based on the rule is the following data type Which does not include the GUID generating mechanism or the Primary Key constraint : Example in MS SQL Server for CUSTOMER Table CustomerUserAccountID FOREITN KEY column (CST4708 Class Use This Example) : CustomerUserAccountID UNIQUEIDENTIFIER NULL Example in Oracle Server for CUSTOMER Table CustomerUserAccountID FOREIGN KEY column (CST3604 Class Use This Example) : CustomerUserAccountID RAW(16) NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

135 Summary & Explanation of Results of Executing Requirement #5d-4.2 throught Requirement #5d-4.5 to determine the Forieng Keys Datatype & Constraints of all the table in scope for CST3604 & CST4708 ❑ In Requirement #5d-4.2 Requirement #5d-4.5 , you were asked to derive the Datatype , Constraints and METADATA for the FOREIGN KEY column for each of the Logical Tables of the Normalized Logical Model in scope of CST3604 & CST4708 and enter the information into each of the Data Dictionary Tables . FOR CST3604 CLASS ONLY ❑ To execute Requirement #5d-4.2 Requirement #5d-4.5 , you are to focus on all the FOREIGN KEY columns METADATA of the Data Dictionary Tables for following 13 Logical Tables of the PILOT Normalized Logical Model :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

136 Project #1 Foreign Key Rule #1 – Foreign Key Column whose PARENT Primary Key IS NOT an IDENTITY or a GUID or other: ❑ In Requirement #5d-4.2 , the focus is on a Foreign Key Column whose PARENT Primary Key IS NOT an IDENTITY . The target is the following Foreign Keys in the following 13 Logical Tables of the PILOT Normalized Logical Model : ▪ CREDITCARD Table MerchantCode – This is a Foreign Key whose Parent Primary Key in the CREDITCARDMERCHANT Table MerchantCode Table IS NOT an IDENTITY . ▪ CUSTOMER Table DriverLicenseNumber – This is a Foreign Key whose Parent Primary Key in the DRIVERLICENSE Table DriverLicenseNumber Table IS NOT an IDENTITY . ▪ CORPORATECUSTOMER Table CompanyID – This is a Foreign Key whose Parent Primary Key in the COMPANY Table CompanyID Table IS NOT an IDENTITY . ❑ Below diagram identifies these 3 Foreign Key Columns : ❑ The first example used in Requirement #5d-4.2 , uses the CUSTOMER Table DriverLicenseNumber Foreign Key as the example and provides this answer. ❑ The second example used in Requirement #5d-4.2 , uses the CORPORATECUSTOMER Table CompanyID Foreign Key as the example and provides this answer. ❑ Based on these two examples, you can easily figure out the Foreign key Datatype and Constraint of the CREDITCARD Table MerchantCode .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

137 Project #1 Foreign Key Rule #2 – Foreign Key Column whose PARENT Primary Key IS an IDENTITY : ❑ In Requirement #5d-4.3 , the focus is on a Foreign Key Column whose PARENT Primary Key IS NOT an IDENTITY . The target is the following Foreign Keys in the following 13 Logical Tables of the PILOT Normalized Logical Model : ▪ RETAILCUSTOMER Table DiscountID – This is a Foreign Key whose Parent Primary Key in the DISCOUNT Table DiscountID Table IS an IDENTITY . ▪ RETAILCUSTOMER Table EZPlusID – This is a Foreign Key whose Parent Primary Key in the EZPLUS Table EZPlusID Table IS an IDENTITY . ❑ Below diagram identifies these 2 Foreign Key Columns : ❑ The first example used in Requirement #5d-4.3 , uses the RETAILCUSTOMER Table DiscountID Foreign Key as the example and provides this answer. ❑ The second example used in Requirement #5d-4.3 , uses the RETAILCUSTOMER Table EZPlusID Foreign Key as the example and provides this answer.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

138 Project #1 Foreign Key Rule #4 – Foreign Key Column whose PARENT Primary Key IS a GUID created and generated by the DBMS: ❑ In Requirement #5d-4.5 , the focus is on a Foreign Key Column whose PARENT Primary Key IS a GUID created & generated by the DBMS . The target is the following Foreign Keys in the following 13 Logical Tables of the PILOT Normalized Logical Model : ▪ CUSTOMER Table CustomerUserAccountID – This is a Foreign Key whose Parent Primary Key in the CUSTOMERUSERACCOUNT Table CustomerUserAccountID Table IS a GUID created & generated by the DBMS . ❑ Below diagram identifies these 1 Foreign Key Columns : ❑ The first example used in Requirement #5d-4.5 , uses the CUSTOMER Table CustomerUserAccountID Foreign Key as the example and provides this answer.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

139 FOR CST4708 CLASS ONLY ❑ To execute Requirement #5d-4.2 Requirement #5d-4.5 , you are to focus on all the FOREIGN KEY columns METADATA of the Data Dictionary Tables for following 4 Logical Tables of the PROOF-CONCEPT Normalized Logical Model :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

140 Project #1 Foreign Key Rule #1 – Foreign Key Column whose PARENT Primary Key IS NOT an IDENTITY or a GUID or other: ❑ In Requirement #5d-4.2 , the focus is on a Foreign Key Column whose PARENT Primary Key IS NOT an IDENTITY . The target is the following Foreign Keys in the following 4 Logical Tables of the PROOF-OF- CONCEPT Normalized Logical Model : ▪ CREDITCARD Table MerchantCode – This is a Foreign Key whose Parent Primary Key in the CREDITCARDMERCHANT Table MerchantCode Table IS NOT an IDENTITY . ❑ Below diagram identifies this 1 Foreign Key Column : ❑ The first example used in Requirement #5d-4.2 , uses the CUSTOMER Table DriverLicenseNumber Foreign Key as the example and provides this answer. ❑ The second example used in Requirement #5d-4.2 , uses the CORPORATECUSTOMER Table CompanyID Foreign Key as the example and provides this answer. ❑ Based on these two examples, you can easily figure out the Foreign key Datatype and Constraint of the CREDITCARD Table MerchantCode .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

141 8. Requirement #5d-4.6 through Requirement #5d-4.25 – In APPENDIX C, DESIGN GUIDELINE DATA TYPE RULE #5 – states “DESIGNING THE DBMSDATATYPE & CONSTRATINS FOR THE REMAINING NON-KEY COLUMNS OF A DICTIONARY TABLE” :  The FLOWCHART below walks you through the STEPS to deriving the DBMSDataType & Constraints for ALL the NON-KEY columns in REQUIREMENTS 5d-4.1 to REQUIREMENTS 5d-4.5 : Detailed Flow Chart for Derriving the DBMSDataType & Constraint for the NON-KEY Columns of a Table as per Requirements 5d-4.6 through Requirements 5d-4.25

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

142 COLUMN/TABLE REQUIREMENT Requirement 5d-4.6: Required Columns MUST be a NOT NULL Constraint. ▪ Execute this requirement on ALL Required ( NOT NULL ) Columns in your Normalize Logical Model scope. 1. Go Do – In the ER/EER Conceptual Model , attributes symbol names were either ONE of these TWO options: 1) OPTION #1 – An attribute name is in BOLD TYPEFACE which means they are REQUIRED ATTRIBUTES , which also means that these columns CANNOT BE BLANK OR EMPTY IN THE FUTURE WHEN INPLEMENTED & BEING USED, THUS MUST BE POPULATED WITH A VALUE WHEN INSERTING A RECORD TO THE TABLE! This option is the most common scenario since most column data is required . a) But in the Normalized Logical Model , unfortunately, there IS NO indication that an attribute is required or mandatory since the default designation in the logical model is the REQUIRED ATTRIBUTES , because it occurs more often. 2) OPTION #2 – An attribute name is in REGULAR TYPEFACE which means they are OPTIONAL ATTRIBUTES , which also means that these columns CAN BE BLANK OR EMPTY IN THE FUTURE WHEN INPLEMENTED & BEING USED, THUS DOES NOT NEED TO BE POPULATED WITH A VALUE WHEN INSERTING A RECORD TO THE TABLE a) But in the Normalized Logical Model , there IS an indication when an attribute/column is optional you will see the designation (O) . More on (O) in the requirement in next requirement 5c-4.5 . 2. Our focus in this requirement is on ALL the ATTRIBUTES , that DON’T HAVE the (O) label in the Normalized Logical Model diagram which is usually most of the table columns in the Normalized Logical Model label and are REQUIRED ATTRIBUTES . 3. The point is that in the Normalized Logical Model , any attributes is assumed REQUIRED if no (O) label is specified for the attribute in the Normalized Logical Model . 4. Below are examples for both MS SQL Server and Oracle Server : Example in MS SQL Server of RENTALAGENCY Table RentalAgencyName column Data type which is a STRING SIZE 50 & REQUIRED (CST4708 Class Use This Example) : RentalAgencyName VARCHAR(50) NOT NULL Example in Oracle Server of RENTALAGENCY Table column RentalAgencyName column Data type which is a STRING SIZE 50 & REQUIRED (CST3604 Class Use This Example) : RentalAgencyName VARCHAR2(50) NOT NULL

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

143  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

144 Requirement 5d-4.7: Optional Columns (O) that ARE NOT FOREIGN KEYS MUST be a NULL Constraint. ▪ Execute this requirement on ALL OPTIONAL ( NULL ) Columns who ARE NOT Foreign Keys in your Normalize Logical Model scope. 1. Go Do – Any column in the Normalized Logical Model , diagram that is marked with a (O) , means is an OPTIONAL column which means the column value can be left BLANK! 2. This means the column MUST HAVE a NULL constraint. 3. IMPORTANT! OPTIONAL columns CANNOT NOT BE PRIMARY KEYS since a primary key cannot be EMPTY , therefore cannot be NULL , but they could appear as FOREIGN KEYS (more on this in next requirement)! 4. Below is an example using for both MS SQL Server and Oracle Server of OPTIONAL (O) constraint column that IS NOT Foreign Key : Example in MS SQL Server of EZPLUS Table EZPlusRewardsEarnedPoints column Data type which is an INT Data Type & OPTIONAL (CST4708 Class Use This Example) : EZPlusRewardsEarnedPoints INT NULL Example in Oracle Server of EZPLUS Table EZPlusRewardsEarnedPoints column Data type which is a NUMBER Data Type & OPTIONAL (CST3604 Class Use This Example) : EZPlusRewardsEarnedPoints NUMBER(6) NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

145 Requirement 5d-4.8: Optional Columns (O) that ARE FOREIGN KEYS MUST be a NULL Constraint. ▪ Execute this requirement on ALL OPTIONAL ( NULL ) Columns who ARE Foreign Keys in your Normalize Logical Model scope. 1. Go Do – Any column in the Normalized Logical Model , diagram that is marked with a (O) , means is an OPTIONAL column which means the column value can be left BLANK! 2. This means the column MUST HAVE a NULL constraint. 3. IMPORTANT! OPTIONAL columns CANNOT NOT BE PRIMARY KEYS since a primary key cannot be EMPTY , therefore cannot be NULL , but FOREIGN KEYS CAN BE OPTIONAL!!! 4. In this case where the FOREIGN KEY is optional , this means the DATA TYPE CONSTRAINT IS A NULL! WHAT THIS MEAN IS THAT FOREIGN KEY IS BLANK IN A TABLE THUS REMOVING ANY DEPENDENCY ON THE PARENT TABLE PRIMARY KEY, THUS INDICATING THE TABLE CAN HAVE ROWS WHOSE FOREIGN KEY IS BLANK OR DOES NOT CONTAIN A VALUE . 5. Below is an example using for both MS SQL Server and Oracle Server of FOREIGN KEYS THAT ARE OPTIONAL (O) constraint : Example in MS SQL Server of RETAILCUSTOMER Table FOREIGN KEY column EZPlusID Data type which is an INT & OPTIONAL (CST4708 Class Use This Example) : EZPlusID INT NULL Example in Oracle Server of RETAILCUSTOMER Table FOREIGN KEY column EZPlusID Data type which is an INT & OPTIONAL (CST3604 Class Use This Example) : EZPlusID NUMBER(10) NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

146 Requirement 5d-4.9: Unique Columns (U) MUST use the UNIQUE Constraint. ▪ Execute this requirement on ALL UNIQUE (U) Columns in your Normalize Logical Model scope. 1. Go Do – Any column in the Normalized Logical Model Diagram that is marked with a (U) , means is a UNIQUE CONSTRAINT COLUMN or VALUE that CANNOT be DUPLICATED in the COLUMN . 2. DON’T confuse UNIQUE columns with a PRIMARY KEY which is also by default UNIQUE . A NON-KEY UNIQUE column has the same characteristics as a primary key where their VALUE CANNOT be DUPLICATED in the COLUMN BUT THEY ARE NOT PRIMARY KEYS! 3. You must APPLY the UNIQUE CONSTRAINT to the DATA TYPE in addition to any other constraint for the data type of this column. 4. Below is an example using for both MS SQL Server and Oracle Server of columns THAT ARE UNIQUE (U) constraint : Example in MS SQL Server of EMPLOYEE Table column SSNumber Data type which is an VARCAR (11) & UNIQUE (CST4708 Class Use This Example) : SSNumber VARCHAR(11) UNIQUE NOT NULL Example in Oracle Server of EMPLOYEE Table column SSNumber Data type which is an VARCAR2(11) & UNIQUE (CST3604 Class Use This Example) : SSNumber VARCHAR2(11) UNIQUE NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

147 Requirement 5d-4.10: Date Columns MUST use the DATE Data Type ▪ Execute this requirement on ALL Columns that STORE DATE VALUES in your Normalize Logical Model scope. 1. Go Do – DATE columns should be a DATE data type NOT A STRING . 2. This is best practice. 3. Below is an example using for both MS SQL Server and Oracle Server of columns THAT ARE DATE Data Types : Example in MS SQL Server of CUSTOMER Table column Birthdate Data type which is a DATE data type (CST4708 Class Use This Example) : Birthdate DATE NOT NULL Example in Oracle Server of CUSTOMER Table column Birthdate Data type which is a DATE data type (CST3604 Class Use This Example) : Birthdate DATE NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

148 Requirement 5d-4.11: Time Columns MUST be stored as MILITARY TIME which is an integer number from 0 to 2400 ▪ Execute this requirement on ALL Columns that STORE TIME VALUES in your Normalize Logical Model scope. 1. Go Do – To minimize complexity, we are going to use MILITARY TIME (NUMBER from 0000 to 2400) using an INTEGER NUMBER DATA TYPE LIMITED to 4 DIGITS SUCH AS NUMBER (4) WITH CHECK CONSTRAINT TO LIMIT VALUES FROM 0000 TO 2400 IN ORACLE SERVER & FOR MICROSOFT SQL SERVER AN SMALLINT WITH CHECK CONSTRAINT TO LIMIT VALUES FROM 0000 TO 2400 . 2. See Requirement #5d for details on using MILITARY TIME (NUMBER from 0000 to 2400) for a Data Type if the explanation here is insufficient . 3. Below is an example using for both MS SQL Server and Oracle Server of columns THAT ARE MILITARY TIME (NUMBER from 0000 to 2400) Data Types : Example in MS SQL Server of RESERVATIONS Table column ReservationPickUpTime which is a column whose data type for uses MILITARY TIME (NUMBER from 0000 to 2400) to represent the time (CST4708 Class Use This Example) : ReservationPickUpTime SMALLINT CHECK( ReservationPickUpTime between 0 and 2400 ) NOT NULL Example in Oracle Server of CUSTOMER Table column Birthdate Data type which is a DATE data type (CST3604 Class Use This Example) : ReservationPickUpTime NUMBER(4) CHECK( ReservationPickUpTime between 0 and 2400 ) NOT NULL 4. Below chart maps standard time to the 4-digit Military Time for a visual:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

149 5. If you are still having difficulties executing this Requirement 5d-4.11 , GO TO APPENDIX F for additional detailed explanation of MILLITARY TIME and how to execute this requirement.  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

150 Requirement 5d-4.12: Datatype for Address StateCode Columns and ANY other column that stores US STATES . ▪ Execute this requirement on ALL Columns that STORE A US STATE VALUES in your Normalize Logical Model scope. This includes the StateCode columns and other columns that store states ! 1. Go Do – For a StateCode Column of an address , use the abbreviated state name such as NY, NJ, VA etc., thus use a CHARACTER DATA TYPE LIMITED to 2 CHARACTERS . 2. Below is an example using for both MS SQL Server and Oracle Server of columns THAT ARE USED TO STORE THE STATE FOR A COUNTRY IN OUR CASE, SPECIFICALLY US STATES: Example in MS SQL Server of CUSTOMER Table column StateCode which is a column whose data type holds TWO CHARACTERS (CST4708 Class Use This Example) : StateCode CHAR(2) NOT NULL Example in Oracle Server of CUSTOMER Table column StateCode which is a column whose data type holds TWO CHARACTERS (CST3604 Class Use This Example) : StateCode CHAR(2) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

151 Requirement 5d-4.13: Zip Code Columns Data Type ▪ Execute this requirement on ALL Zip Code Columns in your Normalize Logical Model scope. 1. Go Do – For a ZipCode Column of an address , provide enough room to accommodate format such as xxxxx-xxxx thus use a STRING DATA TYPE LIMITED to 10 CHARACTERS . 2. Below is an example using for both MS SQL Server and Oracle Server : Example in MS SQL Server of CUSTOMER Table column ZipCode column (CST4708 Class Use This Example) : ZipCode VARCHAR(10) NOT NULL Example in Oracle Server of CUSTOMER Table column ZipCode column (CST3604 Class Use This Example) : ZipCode VARCHAR2(10) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement. Requirement 5c-4.14: Social Security Column ▪ Execute this requirement on ALL Social Security Columns in your Normalize Logical Model scope. 1. Go Do – For the Social Security column in the EMPLOYEE Table use a STRING DATA TYPE LIMITED to 11 CHARACTERS to store SSNumber in the following format (999-99-9999 ). 2. Below is an example using for both MS SQL Server and Oracle Server : Example in MS SQL Server of CUSTOMER Table column SSNumber column (CST4708 Class Use This Example) : SSNumber VARCHAR(11) UNIQUE NOT NULL Example in Oracle Server of CUSTOMER Table column SSNumber column (CST3604 Class Use This Example) : SSNumber VARCHAR2(11) UNIQUE NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

152 Requirement 5d-4.15: Phone Number Column Data Types ▪ Execute this requirement on ALL Social Security Columns in your Normalize Logical Model scope. 1. Go Do – For Phone number columns use an ALPHANUMERIC CHARACTER STRING DATA TYPE LIMITED to 20 CHARACTERS to store Phone Numbers considering USA & international phone formats with +, country code area code & phone numbers .  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement. Requirement 5d-4.16: Currency Column Data Types ▪ Execute this requirement on ALL Social Security Columns in your Normalize Logical Model scope. 1. Go Do – For Columns with a COST value or values is a decimal Currency value such as dollar value etc., use a DECIMAL or FLOATING-POINT data type. 2. Example below. Example in MS SQL Server of FUELOPTION Table column FuelRentalOptionAdditionalCost column (CST4708 Class Use This Example) : FuelRentalOptionAdditonalCost DECIMAL(5, 2) NOT NULL Example in Oracle Server of FUELOPTION Table column FuelRentalOptionAdditionalCost column (CST3604 Class Use This Example) : FuelRentalOptionAdditonalCost NUMBER(5, 2) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

153 Requirement 5d-4.17: CUSTOMER/ RETAILCUSTOMER/ CORPORATECUSTOMER Supertype/Subtype structure CustomerType column Data Type & VEHICLE/ CAR/SUV/MINIVAN/ CARGOVAN VehicleType Column Data Type ▪ Execute this requirement the columns of table(s) where it applies in your Normalize Logical Model scope. 1. Go Do – In the Auto Rental Company database design EER Model & Normalized Logical Model , we have TWO supertype/subtype structures and the special attribute/column that identifies each of the subtype child in each supertype parent : 1) CUSTOMER supertype and it’s two subtype children RETAILCUSTOMER & CORPORATECUSTOMER tables. a) The special attribute/column that identifies each subtype child for the CUSTOMER supertype parent is the CustomerType column . This CustomerType column stores as per the EER Model either the CHARACTER VALUE ‘R’ which represents the RETAILCUSTOMER table or the CHARACTER VALUE ‘C’ which represents the CORPORATECUSTOMER table:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

154 b) The CustomerType column in the Normalized Logical Model . Note logical model does not indicate the value, you will need to look at the EER Model: c) Since the CustomerType column stores ONE CHARACTER VALUE either ‘R’ or ‘ C ’ the data type is as follows: Example in MS SQL Server of CUSTOMER Table column CustomerType column (CST4708 Class Use This Example) : CustomerType CHAR(1) NOT NULL Example in Oracle Server of CUSTOMER Table column CustomerType column (CST3604 Class Use This Example) : CustomerType CHAR(1) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

155 2) Go Do – VEHICLE supertype and it’s four subtype children CAR, SUV, MINIVAN & CARGOVAN tables. a) The special attribute/column that identifies each subtype child for the VEHICLE supertype parent is the VehicleType column . This VehicleType column stores as per the EER Model either the CHARACTER VALUE ‘C’ which represents the CAR table, the CHARACTER VALUE ‘S’ which represents the SUV table, the CHARACTER VALUE ‘M’ which represents the MINIVAN table, or the CHARACTER VALUE ‘V which represents the CARGOVAN table:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

156 b) The CustomerType column in the Normalized Logical Model . Note logical model does not indicate the value, you will need to look at the EER Model: c) Since the VehicleType column stores ONE CHARACTER VALUE either ‘ C ’ , ‘ S ’ , ‘ M ’ , or ‘ V ’ the data type is as follows: Example in MS SQL Server of VEHICLE Table column VehicleType column (CST4708 Class Use This Example) : VehicleType CHAR(1) NOT NULL Example in Oracle Server of VEHICLE Table column VehicleType column (CST3604 Class Use This Example) : VehicleType CHAR(1) NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

157 Requirement 5d-4.18: Boolean Columns (YES/NO or TRUE/FALSE) Data Type. ▪ Execute this requirement the Boolean columns of table(s) where it applies in your Normalize Logical Model scope. 1. Go Do – To store Boolean values to that represent a YES/NO , TRUE/FALSE value, neither Oracle Server or MS SQL Server have a Boolean Data Type . Therefore, use the following Data Types for either DBMS to represent Boolean values : Example in MS SQL Server for CREDITCARD Table column ActivationStatus column storing a BOOLEAN VALUE (CST4708 Class Use This Example) : ActivationStatus BIT NOT NULL Example in Oracle Server of CREDITCARD Table column ActivationStatus column storing a BOOLEAN VALUE (CST3604 Class Use This Example) : ActivationStatus CHAR(1) NOT NULL CHECK( ActivationStatus IN (‘0’, ‘1’ ) )  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement. Requirement 5d-4.19: Email Columns (U) Must be UNIQUE Constraint. ▪ Execute this requirement on all the Email columns of table(s) where it applies in your Normalize Logical Model scope. 1. Go Do – Email Columns are UNIQUE and REQUIRED . 2. Therefore, you must APPLY the UNIQUE and NOT NULL CONSTRAINTS , to all Email Columns :  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

158 Requirement 5d-4.20: Data types for Columns of TABLES that Instance Examples are provided by the Business Requirements ! ▪ Execute this requirement for all the columns of tables that the Business Requirements provide examples given by the business in your Normalize Logical Model scope. 1. Go Do – In the Application Business Requirements there are several entities or tables whose INSTANCE VALUES are listed for you in tabular form thus providing you with an example of the actual DATA and thus you can easily derive the DATA TYPES. 2. A listing of these tables is shown below: 1) Actual INSTANCES examples for the CREDITCARDMERCHANT table MerchantCode which is the Primary key and MerchantName . Note MerchantCode or primary key is a single digit value: 2) Actual INSTANCES examples for the DISCOUNT table DiscountCode and DiscountCodeDescriptions . Note Primary key DiscountID is an IDENTITY : 3) Actual INSTANCES examples for the EZPLUS table EZPlusRewardsCode and EZPlusRewardsEarnedPoints . Note Primary key EZPlusID is an IDENTITY Merchant Code Merchant Name 1 Stax by Fattmerchant 2 Helcim 3 Dharma Merchant Services 4 Payment Depot 5 National Processing 6 Block 7 Intuit Quickbooks 8 PayPal 9 Stripe 10 Flagship Merchant Services 11 Clover Discount ID Discount Code Discount Code Description 1234.. AAA9970054 AAA Membership Discount - 25% off base rate plus 10% donated for breast cancer research. 5678.. GOV8756921 Government Employee Discount - 30% off base rate 9101.. STA3415632 State Employee Discount for 25% off base rate 1213.. VET2055179 Veteran Discount 35% off base rate Plus 10% donation to veteran’s family fund. Etc.. Etc.. Etc.. EZPlus ID EZPlus Rewards Code EZPlus Rewards Earned Points 1234.. EZP9009854637 10000 5678.. EZP1000192461 500 9101.. EZP6493238865 159000 1213.. EZP2005135627 23000 Etc.. Etc..

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

159 4) Actual INSTANCES examples for the VEHICLESTATUS table VehicleStatusID which is the Primary key and VehicleStatusDescriptions . Note VehicleStatusID or primary key is a single digit value. 5) Actual INSTANCES examples for the TRANSMISSIONTYPE table TransmissionTypeID which is the Primary key and TransmissionTypeDescriptions . Note TransmissionTypeID or primary key is a single digit value. 6) Actual INSTANCES examples for the VEHICLERENTALCATEGORY table VehicleRentalCategoryID which is the Primary key and VehicleRentalCategoryName and CategoryDailyRentalRate . Note VehicleRentalCategoryID or primary key is a two-digit value. Transmission Type Transmission Type Description 1 Manual Transmission 2 Automatic Transmission 3 4 Continuously Variable Transmission (e.g., CVT). Semi-automatic Transmission 5 Dual-clutch Transmission 6 Transaxle Transmission

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

160 7) Actual INSTANCES examples for the RESERVATIONSTATUS table ReservationStatusID which is the Primary key and ReservationStatusDescriptions . Note ReservationStatusID or primary key is a single digit value. 8) Actual INSTANCES examples for the FUELOPTION table RentalFuelOptionID which is the Primary key and RentlaFuelOptionDescription and RentalFuelOptionAdditionalCost . Note RentalFuelOptionID or primary key is a single-digit value. 9) Actual INSTANCES examples for the RENTALINSURANCEOPTION table RentalInsuranceOptionID which is the Primary key and RentalInsuranceOptionDescription and RentalInsuranceOptionAdditionalCost . Note RentalInsuranceOptionID or primary key is a single-digit value.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

161 10) Actual INSTANCES of RentalStatusID which is the Primary key and RentalStatusDescriptions . Note RentalStatusID or primary key is a single digit value.  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

162 Requirement 5d-4.21: Data types for all columns of the USState Table ▪ Execute this requirement for the USState table in your Normalize Logical Model scope. 1. Go Do – The USSTATE table stores a listing of State ID, State Code & State Name . This table is to support the User-Interface State Combo-box/List-box control , to allow users to easily select the state code as they enter an address. 2. For the USA , there are 50 states, nevertheless, we will Washington DC which is not a state, for a total of 51 states. We will also include the 5 territories part of the USA such as American Samoa , Guam , Northern Mariana , Puerto Rico and the U.S Virgin Islands . The total is 56 states. 3. Below are the data type to use for this table for Oracle & MS SQL Server : Example in MS SQL Server for USSTATE Table columns (CST4708 Class Use This Example) : StateID TINYINT PRIMARY KEY CHECK (StateID between 1 and 75) StateCode CHAR(2) UNIQUE NOT NULL StateName VARCHAR(50) UNIQUE NOT NULL Example in Oracle Server for USSTATE Table columns (CST3604 Class Use This Example) : StateID NUMBER(2) PRIMARY KEY CHECK (StateID between 1 and 75) StateCode CHAR(2) UNIQUE NOT NULL StateName VARCHAR2(50) UNIQUE NOT NULL  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

163 Requirement 5d-4.22: Data types for all the columns of the Country Table ▪ Execute this requirement for the Country table in your Normalize Logical Model scope. 1. Go Do – The COUNTRY table stores a listing of Country ID , Country 2 Character Code , Country 3 Character Code , & Country Name . This table is to support the User-Interface State Combo-box/List-box control , to allow users to easily select the country as they enter an address. 2. To determine data type for CountryID , you can take into consideration that there are 195 countries officially recognized in the world today. can use is a number with maximum number of countries which is 241, but 195 are officially recognized, I will choose the default of TINYINT data type for MS SQL Server, with a max value of 256. Therefore, for this case where the data type allows for a maximum of 256 values and has an additional 15 additional values (256 - 241) we WILL NOT USE a CHECK constraint for just 15 additional not needed values over 241. 3. Below are the data type to use for this table for Oracle & MS SQL Server : Example in MS SQL Server for COUNTRY Table columns (CST4708 Class Use This Example) : ▪ For MS SQL Server we can determine the data type for CountryID , by taking into consideration that there are 195 countries officially recognized in the world today. Therefore, we can choose the TINYINT data type with a maximum of 256 values and use a CHECK constraint to limit the size to 200 in the event there are new countries created in the next 100+ years. CountryID TINYINT PRIMARY KEY CHECK (CountryID between 1 and 250) CountryCode2Char CHAR(2) UNIQUE NOT NULL CountryCode3Char CHAR(3) UNIQUE NOT NULL CountryName VARCHAR(100) UNIQUE NOT NULL Example in Oracle Server for COUNTRY Table columns (CST3604 Class Use This Example) : ▪ For Oracle Server we can determine the data type for CountryID , by taking into consideration that there are 195 countries officially recognized in the world today. Therefore, we can choose the NUMBER(3) data type with a maximum of 999 values and use a CHECK constraint to limit the size to 200 in the event there are new countries created in the next 100+ years. CountryID NUMBER(3) PRIMARY KEY CHECK (CountryID between 1 and 250) CountryCode2Char CHAR(2) UNIQUE NOT NULL CountryCode3Char CHAR(3) UNIQUE NOT NULL CountryName VARCHAR2(100) UNIQUE NOT NULL

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

164  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

165 Requirement 5d-4.23: EmployeeUserAccount TABLE Employee UserAccountID Primary Key Column ▪ The EMPLOYEE USERACCOUNT table primary key Employee UserAccountID is a column that stores a GLOBAL UNIQUE IDENTIFIER ( GUID ) Alphanumeric string that cannot be duplicated . This Alphanumeric string GUID is GENERATED in the FRONT-END APPLICATION and INSERTED to this column using an SQL INSERT statement from within the front-end application . The goal in this requirement is to SELECT THE CORRECT DATA TYPE FOR THIS PRIMARY KEY COLUMN TO STORE THE GUID GENERATED AND INSERTED BY THE FRONT-END APPLICATION . ▪ Execute this requirement for the Employee UserAccount table in your Normalize Logical Model scope. 1. Go Do – In the EMPLOYEEUSERACCOUNT table , the primary key EmployeeUserAccountID is targeted to STORE a GLOBAL UNIQUE IDENTIFIER (GUID) string generated by the Front-End Application written in C#, Java or other language (Optionally, for more details, you can read Requirement #5e ). NOTE that this GUID Primary Key COULD HAVE or NOT HAVE Business Meaning 2. Details: o The Front-end Application GUID is a GLOBALLY UNIQUE RANDOM UNIQUE ALPHANUMERIC NUMBER that CANNOT BE REPLICATED! o The key point in this example is that this GUID UNIQUE ALPHANUMERIC CHARACTER STRING is being GENERATED BY THE FRONT-END APPLICATION and inserted to Database when the record is being added via a SQL Language INSERT statemen t!!! o Therefore, what is needed to make this Data Type decision in the database, is to use a Data Type that can HOLD this value . o The GUID is an auto-generated Alphanumeric string that looks as follows from C# & Java : C# GUID: {3F2504E0-4F89-11D3-9A0C-0305E82C3301} (38 characters) or simpler version 3F2504E0-4F89-11D3-9A0C-0305E82C3301 (36 characters) . Java GUID: C395BF6C38914BCFA0A8145DDC35C04E (32 characters) . 3. This means that the EMPLOYEEUSERACCOUNT table EmployeeUserAccountID primary key is a regular column in this table but is just going to store a BIG CHARACTER STRING! 4. Below are the data type to use for this primary key column for Oracle & MS SQL Server : Example in MS SQL Server for EMPLOYEEUSERACCOUNT Table EmployeeUserAccountID primary key columns (CST4708 Class Use This Example) : EmployeeUserAccountID UNIQUEIDENTIFIER PRIMARY KEY Example in Oracle Server for EMPLOYEEUSERACCOUNT Table EmployeeUserAccountID primary key columns (CST3604 Class Use This Example) : EmployeeUserAccountID RAW(16) PRIMARY KEY  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

166 Requirement 5d-4.24: CustomerUserAccount TABLE: Customer UserAccountID Primary Key Column ▪ The CUSTOMER USERACCOUNT table primary key Customer UserAccountID is a column that stores a GLOBAL UNIQUE IDENTIFIER ( GUID ) Alphanumeric string that cannot be duplicated . But in this case the Alphanumeric string GUID is GENERATED AUTOMATICALLY by the DATABASE DBMS itself and INSERTED by the DATABASE DBMS itself. The DATABASE does the work for you! The goal in this requirement is to SELECT THE CORRECT DATA TYPE FOR THIS PRIMARY KEY COLUMN TO STORE THE GUID GENERATED AND INSERTED BY THE DATABASE . ▪ Execute this requirement for the Customer UserAccount table in your Normalize Logical Model scope. 1. Go Do – In the CUSTOMERUSERACCOUNT table , is different than the previous table EmployeeUserAccountID in the EMPLOYEEUSERACCOUNT table . This scenario is the opposite approach of NOT GENERATING the GLOBAL UNIQUE IDENTIFIER (GUID) string in the Front-End Application but AUTO-GENERATING the GLOBAL UNIQUE IDENTIFIER (GUID) string in the DATABASE ! This concept is similar to the IDENTITY data type concept, but instead of generating a number, the DATABASE is generating a GUID. (Optionally, for more details, you can read Requirement #5e ). NOTE that this GUID Primary Key COULD HAVE or NOT HAVE Business Meaning. 2. Details: o Like the previous example, the DATABASE GENERATED GUID is a GLOBALLY UNIQUE RANDOM UNIQUE ALPHANUMERIC NUMBER that CANNOT BE REPLICATED! o The key point in this example is that this GUID UNIQUE ALPHANUMERIC CHARACTER STRING is being GENERATED BY THE BACK-END DATABASE and inserted by the Database when the record is being added by the Application via a SQL Language INSERT statement the DATABASE adds the GUID Primary Key at that point !!! o Therefore, what is needed to make this Data Type decision in the database, is to 1) use the DBMS SYNTAX & FEATURE to GENERATE THE GUID and 2) use a Data Type that can HOLD this DATABASE GENERATED GUID value . o The Database Generated GUID looks as follows in MS SQL Server & Oracle : MS SQL: 3F2504E0-4F89-11D3-9A0C-0305E82C3301 (36 characters) . ORACLE: C395BF6C38914BCFA0A8145DDC35C04E (32 characters) . 3. Below are the data type to use for this primary key column for Oracle & MS SQL Server : Example in MS SQL Server for CUSTOMERUSERACCOUNT Table CustomerUserAccountID primary key columns (CST4708 Class Use This Example) : CustomerUserAccountID UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY Example in Oracle Server for CUSTOMERUSERACCOUNT Table CustomerUserAccountID primary key columns (CST3604 Class Use This Example) : CustomerUserAccountID RAW(16) DEFAULT SYS_GUID() PRIMARY KEY  CST4708 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.  CST3604 Class GO DO – Search & identify in the 13 Logical Tables in the Normalized Logical Model where this requirement APPLIES and POPULATE the Data Dictionary Tabular listings with the required METADATA ( Column, Data Type, constraint, etc .) to execute this requirement.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

167 Requirement 5d-4.25: Other remaining Column Data Types ▪ Execute this requirement for ALL remaining tables in your Normalize Logical Model scope. 1. Go Do #30 – For other remaining tables/columns not listed in Requirement #5d-4.1 through Requirement #5d-4.24 do the following: 1) The first thing you should do is apply DESIGN GUIDELINES DATA TYPE RULE #2 and look at the business requirements to verify if examples or instances of the target attributes exists . ‐ For example, for the CAR table TrunkCapacity column, the Business Requirements show an instance example of 18.5 cubic feet , therefore this is a decimal or floating-point number. Decimal being a good option. Also, in the SUV table , for the Towingcapacity column an example is given of 3,000 lbs ., in the Business Requirements , which means this could be an integer with a limited value maybe 5000 since an SUV cannot tow anything very large. But even if you choose a regular integer with no limit, this is a number or a decimal number if you decide to give it values after a decimal point. The Business Requirements also show an example of the CargoVan Table with a CargoCapacity example of 245 cubic feet and MaximumPayload example of 3,880 lbs . These values give in the Business Requirements give you cluea as to what data type to use. 2) Leverage DESIGN GUIDELINES DATA TYPE RULE #1 TO #5 which includes the 7 Primary Key rules for Primary keys . 3) See the 3-TABLE Data Type example (CUSTOMER, PRODUCT & PURCHASE) at the beginning of Requirement #5 to get an idea of how I made those data type decisions. For example, the names, addresses etc., Data Types that I used. IMPORTANT! This example is NOT your project but another scenario, nevertheless there are some selections which you can leverage and use as an example to create your own . 4) You can also look at the 8 guidelines for selecting datatype . 5) Finally, you can ask Prof. Rodriguez for guidance on a particular data type, BUT first try it yourself and verify with the professor if you are not sure about your choice .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

168 9. Based on the above table Requirement 5d-4.1 through Requirement 5d-4.25 , you either have been given the data type or given instructions on what data type to use. 10. Note that in Requirement 5d-4.1 guidance on PRIMARY KEYS is provided and examples that you can leverage as well. 11. In Requirement 5d-4.2 and Requirement 5d-4.24 you have DATA TYPE examples for many columns of your DATA DICTIONARY for you to leverage. For the remaining columns across your Data Dictionary, follow the experience gained so far and Requirement 5d-4.25 . 12. At the end of Requirement #5 , you should have the following: 1) For CST4708 Class – 13 DICTIONARY TABLES fully populated with MS SQL SERVER DATA TYPE & METADATA . 2) For CST3604 Class – 13 DICTIONARY TABLES fully populated with ORACLE SERVER DATA TYPE & METADATA 13. YOU WIL BE GRADED on your choice of DATA TYPE targeting Microsoft SQL SERVER DBMS for CST4708 and ORACLE SERVER DBMS for CST3604 . Use the OFFICIAL DATA TYPE LIST FOR EACH DBMS found in the appendix of this document and follow the design guidelines covered in class lecture discussed in class to select your data types . 14. In some cases, where your answer is NOT easily clear, you may want to provide a short comment on why a data type was selected. Not trying to give you more work, but in scenario it makes sense to me why you chose something, provide a short comment. 15. Follow the Table with Requirement 5d-4.1 through Requirement 5d-4.25 in detail. Remember that errors made with the data type selections can have severe consequences on the entire application and can cause future delays redesigning the application because of wrong choices in the data types .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

169 ❖ Requirement #5e – THIS SECTION IS THE THEORETICAL DETAILS FOR COLUMN THAT WILL STORE TIME DATA AS MILITARY TIME. THIS THEORY WAS ALREADY COVERED IN REQUIREMENT 5d- 4.11 . SKIP THIS REQUIREMENT IF YOU HAVE SUCCESSFULLY IMPLEMENTED REQUIREMENT 5d-4.11 FOR STORING MILITARY TIME VALUES IN COLUMNS THAT REQUIRED TIME . IF YOU NEED A DEEPER ANALYSIS, GO TO APPENDIX F OF THIS DOCUMENT : 1. GO TO APPENDIX F , if you need additional theory and explanation in addition to what you did in Requirement 5d-4.11 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

170 ❖ Requirement #5f – THIS SECTION PROVIDES A DETAILED ANALYSIS AND THEORY FOR THE EmployeeUserAccountID PRIMARY KEY in the EMPLOYEEUSERACCOUNT table & CustomerUserAccountID PRIMARY KEY in the CUSTOMERUSERACCOUNT table WHICH WILL STORE GLOBALLY UNIQUE IDENTIFIER (GUID) RANDOM CHARACTER STRING. THIS THEORY WAS ALREADY COVERED IN REQUIREMENT 5d-4.21 & REQUIREMENT 5d-4.22 . SKIP THIS REQUIREMENT IF YOU HAVE SUCCESSFULLY IMPLEMENTED REQUIREMENT #5d-4.21 & REQUIREMENT #5d-4.22 FOR THE DATA TYPE OF THE PRIMARY KEY COLUMNS THAT STORE A GUID FOR EMPLOYEEUSERACCOUNT & CUSTOMERUSERACCOUNT TABLES IN PREVIOUS SECTION . IF YOU NEED A DEEPER ANALYSIS, GO TO APPENDIX G OF THIS DOCUMENT 1. GO TO APPENDIX F , if you need additional theory and explanation in addition to what you did in Requirement 5d-4.11 . ❖ FINAL COMMENTS: ➢ ALTHOUGH READING THIS SECTION WAS OPTIONAL, NOTE THAT ANSWERS TO IMPLEMENTATION STATEMENTS FOR REQUIREMENT #7 ARE GIVEN IN APPENDIX G. ➢ IF YOU DO SKIP THIS SECTION, I RECOMMEND YOU COME BACK TO THIS SECTION WHEN CREATING THE TABLES IN REQUIREMENT #7 FOR EMPLOYEE USER ACCOUNT & CUSTOMER USER ACCOUNT SINCE THE ANSWERS ARE SHOWN.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

171 ❖ Requirement #5f – REQUIREMENT FORMAT & PRESENTATION : 1. As stated in Requirement #1b , remember to CREATE A PARAGRAPH(S) DESCRIBING THIS SECTION AND WHAT YOU ARE DELIVERING . 2. Also, as per Requirement #1c , make sure this PARAGRAPH(S) HAS TO BE CUSTOMER READY!! 3. Note only a SHORT PARAGRAPH(S) IS REQUIRED . 4. AT THIS POINT YOU ARE DONE WITH REQUIREMENT #5!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

172 Requirement #6 (20 POINTS) – (DESIGN PHASE) – Create the Physical Data Model Diagram USING A COMBINATION of the Normalized Logical Diagram of Requirement #4 and the Data Dictionary Tables of Requirement #5 targeting MS SQL SERVER for CST4708 and ORACLE DBMS for CST3604 Database Design Deliverable #5 – The Normalized Logical Model Diagram ❑ Create the Physical Model/Schema Design diagram by RE-DRAWING the Normalized Logical Model of Requirement #4 & ADDING the Data Dictionary tables of Requirements #5 to create this Physical Model/Schema Design diagram : For both CST4708 & CST3604 CLASS ❖ Requirement #6a – START by READING the instructions in Requirement #1h Section 3 Sub-Section-Header 13 for an overview of the Database Design Deliverable #5 – Physical Model Data Dictionary Requirements 1. Requirement #6a GO DO #1: Read Requirement #1h Section 2 Sub-Section-Header 13 which describes the Database Design Deliverable #5 – Physical Model Schema Diagram . This section provides an overview of this REQUIREMENT #6 and descriptions that can help you create the sub- section-header paragraphs for this requirement. 2. The Physical Model Schema Diagram is the design deliverable Database Developer (that means you!) is to use to IMPLEMENT the Database Management System (DBMS) Application using Microsoft SQL Server DBMS or Oracle Server DBMS . It is the final design component before implementation.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

173 ❖ Requirement #6b – (DIAGRAM #3) CREATE PHYSICAL MODEL using a DRAWING TOOL : 1. Using a combination of the NORMALIZED LOGICAL Model (LIMITED PILOT for CST3604 or PROOF-OF-CONCEPT for CST4708) listed in Requirement #4 , and the DATA DICTIONARY of Requirement #5 and a MODELING/DRAWING TOOL such as Visio , LucidChart , Draw.io , etc., to CREATE the PHYSICAL MODEL SCHEMA DESIGN DIAGRAM . 2. Hand-written drawing WILL NOT BE ACCEPTED! Use a DRAWING TOOL. Even when using a DRAWING TOOL DO NOT draw the Schema Tables or Relationships in the diagram using free-hand drawing with the mouse, use RETANGLES, LINES etc., to build your Physical Model/Schema Design diagram . 3. Items you will need to execute this requirement: CST4708 CLASS ONLY: 1) MS SQL SERVER DBMS : a) Have the PROOF-OF-CONCEPT Normalized Logical Model available with the 4 Logical Tables & ALL the Relationships Lines between the Logical Tables you will need to RE- DRAW to CREATE the Physical Schema Design Diagram . b) A Drawing Tool such as Visio , LucidChart , Draw.io , etc . DO NOT USE A DBMS specific tool to create this diagram, ONLY A GENERIC DRAWING PROGRAM ! c) The 4 Data Dictionary Tables from Requirement #5 to extract the Column Name, DBMS Datatype & Constraint for each column to add to Physical Schema Design Diagram you are CREATING . CST3604 CLASS ONLY: 2) ORACLE SERVER DBMS : a) The LIMITED PILOT Normalized Logical Model handy with the 13 Logical Tables & ALL the Relationships Lines between the Logical Tables you will need to RE-DRAW to CREATE the Physical Schema Design Diagram . b) A Drawing Tool such as Visio , LucidChart , Draw.io , etc . DO NOT USE A DBMS specific tool like ORACLE DATA MODELER to create this diagram, ONLY A GENERIC DRAWING PROGRAM ! c) The 13 Data Dictionary Tables from Requirement #5 to extract the Column Name, DBMS Datatype & Constraint for each column to add to Physical Schema Design Diagram you are CREATING .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

174 4. In the next page(s) there is an example of the high-level steps required to create the Physical Model Design Diagram from the combination of the Normalized Logical Model and the Data Dictionary Tables for both MS SQL Server Data Types & Oracle Server Data Types . This example is to give you an idea of what is required STEPS for building the Physical Model Design Diagram . 5. In the example, we assume another Normalized Logical Model containing CUSTOMER, PURCHASE & PRODUCT tables, and their respective RELATIONSHIPS . The objectives are to REDRAW the Normalized Logical Model and ADD to every LOGICAL TABLE in the DIAGRAM the DBMS DATA TYPE & CONSTRAINT from the Data Dictionary to every column attribute of every LOGICAL TABLE . to CREATE the Physical Model Design Diagram . 6. Steps are as follows: a) STEP 1 in the example, is to take a COPY/RE-DRAW of the Normalized Logical Model containing the LOGICAL TABLE and their respective RELATIONSHIPS in scope. Once you have COPIED/RE- DRAWN the Normalized Logical Model Diagram thus created a new one, then you are ready for STEP 2 . b) In STEP 2 , for every LOGICAL TABLE in the NEW Physical Model Design Diagram created in scope, MODIFY each LOGICAL TABLE by ADDING to each column attribute name the DBMS DATA TYPE & list of CONSTRAINTS from the Data Dictionary tables of Requirement #5 . Once you have ADDED the DBMS DATA TYPE & list of CONSTRAINTS from the Data Dictionary tables to the NEW Normalized Logical Model Diagram , you are ready for STEP 3 . c) STEP 3 is the outcome which is the Physical Model Design Diagram created from the combination of the Normalized Logical Model Diagram and the Data Dictionary Tables DATA TYPES & CONSTRAINTS . The Physical Model Design Diagram is a REPLICA of the Normalized Logical Model Diagram but containing the DBMS DATA TYPE & list of CONSTRAINTS from the Data Dictionary tables of Requirement #5 . See the illustration shown on the next page for a VISUAL REPRESENTATION OF THE STEPS . 7. SUPER IMPORTANT : - Note that the resultant Physical Model Design Diagram is IDENTICAL to the Normalized Logical Model EXCEPT the Physical Model Design Diagram INCLUDES DATA TYPES & CONSTRAINTS FROM THE DATA DICTIONARY TABLES . - Since the Physical Model Design Diagram is IDENTICAL to the Normalized Logical Model , THIS MEANS YOU NEED TO CREATE THE Physical Schema Model Diagram EXACTLY LIKE THE Normalized Logical Model INCLUDING ALL TABLES & RELATIONSHIPS OF THE Normalized Logical Model & then ADD the DATA TYPES & METADATA from the Data Dictionary Tables .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

175 MS SQL Server (CST4708 CLASS ONLY) 8. Therefore, the results should be as follows for CST4708 Class Only : - For CST4708 CLASS at the end of this requirement, you should have a Physical Model Design Diagram with the following:  4 Schema tables each with all the attribute/column names for the table, and for each column the MS SQL Server Datatypes & Constraint .  1 Relationships lines with arrows pointing to the correct Logical Table as shown in the PROOF-OF-CONCEPT Normalized Logical Model Diagram . - See below for an example on 3 STEPS to create the Physical Schema Design Diagram Using MS SQL SERVER using another database design with only the 3 Schema Tables: TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ CST4708 Lecture 6B – DB Design Part 2-Physical Design ‐ CST3504 Lecture 5A – Dictionary & Physical Diagram ▪ Book: Modern Database Management (Chapter 5)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

176 Oracle Server (CST3604 CLASS ONLY) 9. The results should be as follows for CST3604 Class Only : - For CST3604 CLASS at the end of this requirement, you should have a Physical Model Design Diagram with the following:  13 Schema tables each with all the attribute/column names for the table, and for each column the Oracle Server Datatypes & Constraint .  10 Relationships lines with arrows pointing to the correct Logical Table as shown in the LIMITED PILOT Normalized Logical Model Diagram . - See below for an example on 3 STEPS to create the Physical Schema Design Diagram Using Oracle SERVER using another database design with only the 3 Schema Tables: ❖ Requirement #6b – COPY/PASTE YOUR FINAL PHYSICAL DIAGRAM to the Design/Implementation document of Requirement #1 TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ CST3504 Lecture 5A – Dictionary & Physical Diagram ▪ Book: Modern Database Management (Chapter 5)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

177 ❖ Requirement #6c – COPY/PASTE YOUR FINAL PHYSICAL DIAGRAM to the Design/Implementation document of Requirement #1 1. AFTER YOU CREATE YOUR PHYSICAL MODEL DIAGRAM USING A DRAWING TOOL, COPY/PASTE you Physical Model Diagram to your Design/Implementation Project Document . 2. This will be your 3 rd diagram. MS SQL Server (CST4708 CLASS ONLY) 3. Below is what the final diagram known as the Physical Model Design Diagram looks like using MS SQL Server for our 3-table example ( for CST4708 Class your version will have 4 Tables and 1 Relationship Lines with Arrows pointing to corresponding tables ): ▪ Note Physical Schema Design Diagram is exactly like the Normalized Logical Model Diagram . ▪ EXCEPT in the Physical Schema Design Diagram the attributes or columns of the include the Datatypes & Constraints from the Data Dictionary Tables.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

178 Oracle Server (CST3604 CLASS ONLY) 4. Below is what the final diagram known as the Physical Model Design Diagram looks like using Oracle Server for our 3-table example ( for CST3604 Class your version will have 13 Tables and 10 Relationship Lines with Arrows pointing to corresponding tables ): ▪ Note Physical Schema Design Diagram is exactly like the Normalized Logical Model Diagram . ▪ EXCEPT in the Physical Schema Design Diagram the attributes or columns of the include the Datatypes & Constraints from the Data Dictionary Tables.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

179 For both CST4708 & CST3604 CLASS ❖ Requirement #6d – REQUIREMENT FORMAT & PRESENTATION 1. As stated in requirement #1b & 1c , within the correct SUB-HEADER , remember to CREATE A PARAGRAPH(S) DESCRIBING THIS SECTION AND WHAT YOU ARE DELIVERING . 2. ALSO, THIS PARAGRAPH(S) SHOULD BE CUSTOMER READY! ❖ Requirement #6e – SAVE THE DRAWING AS A JPG OR OTHER IMAGE FORMAT AND SUBMIT WITH THIS PROJECT/SPRINT 1. Save & Name the diagram as a JPEG or other image format. 2. Submit the image file alongside your Design/Implementation Project Document . ❖ Requirement #6f – GO TO REQUIREMENT #11c FOR INSTRUCTIONS ON SUBMITTING SPRINT #2 1. GO TO Requirement #11c , for detailed instructions on what is needed to submit SPRINT #2 and email attachment and subject line information.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

180 Section 5e – Execute Project Management Methodology Development & Implementation Phase SPRINT #3 Requirements #7 & #8 ❑ In this section the Database Developer will execute the Development & Implementation Phase and output the requires deliverable from this phase as indicated in this requirement. ❑ The Database Developer (YOU) will now execute this Development & Implementation Phase and output the requires deliverable from this phase as indicated in this requirement. ❑ Overview of objectives, activities and deliverables for this phase are shown below: Development & Implementation PHASE – Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

181 Requirement #7 (20 POINTS) – ( Phase 4 – DEVELOPMENT & IMPLEMENTATION PHASE ) – Implement the Physical Model Design Diagram by CREATING & EXECUTING a Script File that contains ALL the Data Definition Language (DDL) CREATE TABLE Statements to Develop the Physical Model Schema in MS SQL Server for CST4708 Class or Oracle Server for CST3604 Class using each DBMS specific Admin Tools Database Design Deliverable #6 – Development & Implementation ❑ Implement your schema design (Physical Model) in MS SQL Server for CST4708 Class & Oracle Server for CST3604 Class as follows: ❖ Requirement #7a – START by READING the instructions in Requirement #1j Section 3 Sub-Section-Header 14 for an overview of the Database Design Deliverable #6 – Development & Implementation Requirements 1. Requirement #7a GO DO #1: Read Requirement #1j Section 2 Sub-Section-Header 14 which describes the Database Design Deliverable #6 – Development & Implementation . This section provides an overview of this REQUIREMENT #7 and descriptions that can help you create the sub- section-header paragraphs for this requirement in addition to other information provided in this requirement. 2. The Development & Implementation is the Database Developer (that means you!) developing/implementing the design that finalized with the Physical Schema Design Diagram of REQUIREMENT #6 . In this section the Database Developer is to IMPLEMENT that Database Management System (DBMS) Application using Microsoft SQL Server DBMS or Oracle Server DBMS .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

182 ❖ Requirement #7b – ( Database SCRIPT FILE #1 ) CREATE A SCRIPT FILE TO HOST THE DATA DEFINITION LANGUAGE (DDL) CREATE TABLE STATEMENTS THAT THE DATABASE DEVELOPER WILL EXECUTE TO PHYSICALLY IMPLEMENT THE DATABASE SCHEMA: MS SQL Server (CST4708 CLASS ONLY) 1. Requirement #7b GO DO #1: Using Microsoft SQL Management Studio , CREATE and NAME a SCRIPT FILE targeted to store all the DDL CREATE TABLE statements to be used to implement the Physical Model Design Diagram . This will be your FIRST SCRIPT FILE ( CREATE TABLE SCRIPT FILE #1 ). 2. At this point your Database Development Environment should be ready & setup via HW #1. See HW#1 & CST4708 Lecture 6A for installation of Microsoft SQL Server Community Edition & Microsoft SQL Management Studio for information on setting up your development environment . 3. See CST4708 Lecture 6C to learn how to create & use the Script File using MS SQL Server & Microsoft SQL Management Studio to develop & implement the Physical Model Schema Design Diagram in MS SQL Server . 4. Requirement #7b GO DO #2: SAVE your script file & make sure you NAME your Script File with a name that reflects your project, such as Auto Management Database Create Table Script File , Banking Management System Database Create Table Script File etc., depending on your project. ➢ IMPORTANT!!!!!  This script file will host/contain ALL DDL/ CREATE TABLE statements.  DO NOT execute a CREATE TABLE statement and then delete the CREATE TABLE statement from your script after execution and repeat this step thus deleting any history of all the CREATE TABLE statements ! This is BAD !!  The Script File is to contain ALL the CREATE TABLE statements!!! This way you have a history of your query statements and can go back and re-execute them as needed .  ALL your SCRIPT FILES serve a very important part in the OPERATIONAL/MAINTENANCE PHASE , and that is to be available & ready in the event of a DISASTER/RECOVERY scenario where your physical SERVER COMPUTER is corrupted or damaged and you need to reimplement your entire application in a NEW SERVER COMPUTER . The SCRIPT FILES are used to immediately re-execute the QUERIES, CREATE TABLE STATEMENTS or ANY SERVER-SIDE CODE that needs to be executed to quickly get your database back in production !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

183 Oracle Server (CST3604 CLASS ONLY) 1. Requirement #7b GO DO #1: Using Oracle SQL Developer , CREATE and NAME a SCRIPT FILE targeted to store all the DDL CREATE TABLE statements to be used to implement the Physical Model Design Diagram . This will be your FIRST SCRIPT FILE ( CREATE TABLE SCRIPT FILE #1 ) 2. At this point your Database Development Environment should be ready & setup via HW #1. See HW#1 & CST3504 Lecture 6A for installation of Oracle & SQL Developer for information on setting up your development environment . 3. See CST3504 Lecture 6B to learn how to create & use the Script File & Oracle SQL Developer to develop & implement the Physical Model Schema Design Diagram in Oracle Server . 4. Requirement #7b GO DO #2: SAVE your script file & make sure you NAME your Script File with a name that reflects your project, such as Auto Management Database Create Table Script File , Banking Management System Database Create Table Script File etc., depending on your project. ➢ IMPORTANT!!!!!  This script file will host/contain ALL DDL/ CREATE TABLE statements.  DO NOT execute a CREATE TABLE statement and then delete the CREATE TABLE statement from your script after execution and repeat this step thus deleting any history of all the CREATE TABLE statements ! This is BAD !!  The Script File is to contain ALL the CREATE TABLE statements!!! This way you have a history of your query statements and can go back and re-execute them as needed .  ALL your SCRIPT FILES serve a very important part in the OPERATIONAL/MAINTENANCE PHASE , and that is to be available & ready in the event of a DISASTER/RECOVERY scenario where your physical SERVER COMPUTER is corrupted or damaged and you need to reimplement your entire application in a NEW SERVER COMPUTER . The SCRIPT FILES are used to immediately re-execute the QUERIES, CREATE TABLE STATEMENTS or ANY SERVER-SIDE CODE that needs to be executed to quickly get your database back in production !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

184 ❖ Requirement #7c – IMPLEMENT the PHYSICAL SCHEMA DIAGRAM CREATED IN REQUIREMENT #6 , BY CREATING DATA DEFINITION LANGUAGE (DDL) CREATE TABLE STATEMENTS IN A SCRIPT FILE & EXECUTING EACH OF THE CREATE TABLE STATEMENT TO IMPLEMENT THE ENTIRE DATABASE APPLICATION: MS SQL Server (CST4708 CLASS ONLY) 1. Requirement #7c GO DO #1: Using Microsoft SQL Management Studio , IMPLEMENT the entire PHYSICAL MODEL SCHEMA DESIGN DIAGRAM by creating all tables and relationships (Foreign- key/Primary-key) using DDL CREATE TABLE statements INSIDE THIS SCRIPT FILE . 2. Requirement #7c GO DO #2: EXECUTE each of the CREATE TABLE statements in the appropriate order to create your physical schema . 3. Requirement #7c GO DO #3: Make sure you NAME & SAVE your Script File . 4. The STEPS , goals & process are illustrated below: Step 1 Have Physical Schema Design Diagram Ready Step 2 DB Developer Exe cutes Each Create Table Statement to implement the Tables & Relationships in the Database Step 3 DBMS Application Implemented

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

185 Steps on how to implement this Requirement STEP #1 – Have your Physical Model Schema Design Diagram Ready ❑ Below is the 3 Table example Physical Model Schema Design Diagram we have been using as an example in REQUIREMENT #5 & REQUIREMENT #6 . Let’s use this diagram again to demonstrate how to use the CREATE TABLE STATEMENT using MS SQL SERVER DBMS to IMPLEMENT this Physical Model Schema Design Diagram in the database.  I will review and teach the theory on how to execute this process in Lecture 6C – CST4708_Part3_Implementation . What is provided in this section is a high-level overview of the steps. TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ Lecture 6C – CST4708_Part3_Implementation ▪ Book: CST3504 Modern Database Management (Chapter 6)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

186 STEP #2 – Determine the ORDER that you will create the Tables and Relationships from the Physical Model Schema Design Diagram of Requirement #6 ❑ The order in which you create the Tables and Relationships is very important. ❑ If you don’t plan the order of creating the Tables and Relationships either you won’t be able to create a table or worse, create the table wrong! ❑ You MUST follow this ORDER OF TABLE CREATION RULE: 1. Rule #1 – You CANNOT CREATE A TABLE that HAS FOREIGN KEY COLUMNS , WITHOUT FIRST CREATING the PARENT TABLES WITH PRIMARY KEY FIRST : o What that means is PARENT TABLES WITH PRIMARY KEY FIRST, FOREIGN KEY TABLES AFTER! o You cannot try to CREATE a TABLE that has FOREIGN KEY columns BEFORE you CREATE the PARENT TABLE with Primary key FIRST! THE DATABASE WILL NOT LET YOU DO IT! o Why? Think about it, HOW CAN YOU EXIST WITHOUT YOUR PARENTS EVER EXISTING? The PARENT MUST BE FIRST, THE CHILDREN AFTER! SAME APPLIES TO TABLE & RELATIONSHIP CREATION. o For example: - In the following 13 table snapshot of the 33 tables in the Normalized Logical Model , the CUSTOMER TABLE has a DriverLicenseNumberID FK and CustomerUserAccountID FK , which means YOU CANNOT CREATE CUSTOMER TABLE , until YOU ALREADY HAVE CREATED DRIVERLICENSE TABLE and CUSTOMERUSERACCOUNT TABLE . - So, the DRIVERLINCENSE & CUSTOMERUSERACCOUNT TABLES HAVE TO BE CREATED FIRST BEFORE YOU CAN CREATE CUSTOMER!!! - This applies to ANY TABLE THAT HAS FOREIGN KEY(S)! - See example below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

187 2. Rule #2 – Based on Rule #1 , PLAN the ORDER to CREATE the TABLES in your schema o With Rule #1 in mind, you need to PLAN the ORDER you will CREATE the TABLES before executing the CREATE TABLE STATEMENTS . o Example: - For the 13 -table example, using Rule #1 , one possible order would be to CREATE the TABLES in the ORDER shown below: - PLAN HOW YOU WILL CREATE THE TABLES. MY EXAMPLE ABOVE IS ONE WAY TO DO THIS, THERE ARE OTHER POSSIBLE APPROACH . - For example, you could start with USState and Country TABLES FIRST since they have no Foreign Keys . - Also, CreditCard TABLE has no Foreign Key either so you can start there. - There are several options for you to create this order. It is up to you to decide!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

188 STEP #3 – Use MS SQL Server Data Definition Language CREATE TABLE STATEMENT to create all the Tables and Relationships based on the Physical Model Schema Design Diagram of Requirement #6 ❑ Below are the 3 CREATE TABLE STATEMENT SYNTAX using MS SQL SERVER DBMS syntax, to IMPLEMENT this 3-table example Physical Model Schema Design Diagram example in the MS SQL SERVER DBMS database are shown below: 1. Creating a CUSTOMER TABLE using CREATE TABLE STATEMENT SYNTAX #1 : 2. Creating a PRODUCT TABLE using CREATE TABLE STATEMENT SYNTAX #2 :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

189 3. Creating a PURCHASE TABLE and TWO RELATIONSHIPS using CREATE TABLE STATEMENT SYNTAX #3 :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

190 STEP #4 – When all tables & relationships have been created using CREATE TABLE STATEMENTS in STEP #2, the database Design has been implemented in MS SQL SERVER DBMS ❑ Below diagram shows the 3 IMPLEMENTED TABLES & 2 RELATIONSHIPS in MS SQL SERVER DBMS generated from MS SQL SERVER MANAGEMENT STUDIO admin tool:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

191 Oracle Server (CST3604 CLASS ONLY) 1. Requirement #7c GO DO #1: Using Oracle SQL Developer , IMPLEMENT the entire PHYSICAL MODEL SCHEMA DESIGN DIAGRAM by creating all tables and relationships (Foreign- key/Primary-key) using DDL CREATE TABLE statements INSIDE THIS SCRIPT FILE . 2. Requirement #7c GO DO #2: EXECUTE each of the CREATE TABLE statements in the appropriate order to create your physical schema . 3. Requirement #7c GO DO #3: Make sure you NAME & SAVE your Script File . 4. The STEPS , goals & process are illustrated below: Step 1 Have Physical Schema Design Diagram Ready Step 2 DB Developer Exe cutes Each Create Table Statement to implement the Tables & Relationships in the Database Step 3 DBMS Application Implemented

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

192 Steps on how to implement this Requirement STEP #1 – Have your Physical Model Schema Design Diagram Ready ❑ Below is the 3 Table example Physical Model Schema Design Diagram we have been using as an example in REQUIREMENT #5 & REQUIREMENT #6 . Let’s use this diagram again to demonstrate how to use the CREATE TABLE STATEMENT using ORACLE SERVER DBMS to IMPLEMENT this Physical Model Schema Design Diagram in the database.  I will review and teach the theory on how to execute this process in Lecture 6C – CST4708_Part3_Implementation . What is provided in this section is a high-level overview of the steps. TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ Lecture 6B - CST3504 DB Dev with Oracle PART 2 ▪ Book: CST3504 Modern Database Management (Chapter 6)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

193 STEP #2 – Determine the ORDER that you will create the Tables and Relationships from the Physical Model Schema Design Diagram of Requirement #6 ❑ The order in which you create the Tables and Relationships is very important. ❑ If you don’t plan the order of creating the Tables and Relationships either you won’t be able to create a table or worse, create the table wrong! ❑ You MUST follow this ORDER OF TABLE CREATION RULE: 1. Rule #1 – You CANNOT CREATE A TABLE that HAS FOREIGN KEY COLUMNS , WITHOUT FIRST CREATING the PARENT TABLES WITH PRIMARY KEY FIRST : o What that means is PARENT TABLES WITH PRIMARY KEY FIRST, FOREIGN KEY TABLES AFTER! o You cannot try to CREATE a TABLE that has FOREIGN KEY columns BEFORE you CREATE the PARENT TABLE with Primary key FIRST! THE DATABASE WILL NOT LET YOU DO IT! o Why? Think about it, HOW CAN YOU EXIST WITHOUT YOUR PARENTS EVER EXISTING? The PARENT MUST BE FIRST, THE CHILDREN AFTER! SAME APPLIES TO TABLE & RELATIONSHIP CREATION. o For example: - In the following 13 table snapshot of the 33 tables in the Normalized Logical Model , the CUSTOMER TABLE has a DriverLicenseNumberID FK and CustomerUserAccountID FK , which means YOU CANNOT CREATE CUSTOMER TABLE , until YOU ALREADY HAVE CREATED DRIVERLICENSE TABLE and CUSTOMERUSERACCOUNT TABLE . - So, the DRIVERLINCENSE & CUSTOMERUSERACCOUNT TABLES HAVE TO BE CREATED FIRST BEFORE YOU CAN CREATE CUSTOMER!!! - This applies to ANY TABLE THAT HAS FOREIGN KEY(S)! - See example below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

194 2. Rule #2 – Based on Rule #1 , PLAN the ORDER to CREATE the TABLES in your schema o With Rule #1 in mind, you need to PLAN the ORDER you will CREATE the TABLES before executing the CREATE TABLE STATEMENTS . o Example: - For the 13 -table example, using Rule #1 , one possible order would be to CREATE the TABLES in the ORDER shown below: - PLAN HOW YOU WILL CREATE THE TABLES. MY EXAMPLE ABOVE IS ONE WAY TO DO THIS, THERE ARE OTHER POSSIBLE APPROACH . - For example, you could start with USState and Country TABLES FIRST since they have no Foreign Keys . - Also, CreditCard TABLE has no Foreign Key either so you can start there. - There are several options for you to create this order. It is up to you to decide!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

195 STEP #3 – Use ORACLE Server Data Definition Language CREATE TABLE STATEMENT to create all the Tables and Relationships based on the Physical Model Schema Design Diagram of Requirement #6 ❑ Below are the 3 CREATE TABLE STATEMENT SYNTAX using ORACLE SERVER DBMS syntax, to IMPLEMENT this 3-table example Physical Model Schema Design Diagram example in the ORACLE SERVER DBMS database are shown below: 1. Creating a CUSTOMER TABLE using CREATE TABLE STATEMENT SYNTAX #1 : 2. Creating a PRODUCT TABLE using CREATE TABLE STATEMENT SYNTAX #2 :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

196 3. Creating a PURCHASE TABLE and TWO RELATIONSHIPS using CREATE TABLE STATEMENT SYNTAX #3 :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

197 STEP #4 – When all tables & relationships have been created using CREATE TABLE STATEMENTS in STEP #2, the database Design has been implemented in ORACLE SERVER DBMS ❑ Below diagram shows the 3 IMPLEMENTED TABLES & 2 RELATIONSHIPS in ORACLE SERVER DBMS generated from ORACLE SQL DEVELOPER admin tool:  Note that the example above does not match exactly the Create Table Statements in previous page because I did not have the Oracle environment setup at the time of creating this section.  Nevertheless, the example above was copied from the notes and closely matches the Create Table Statements used in previous pages.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

198 For both CST4708 & CST3604 CLASS ❖ Requirement #7d – WHEN EVERY CREATE TABLE STATEMENT IS EXECUTED AND TABLE OBJECTS ARE CREATED, COPY/PASTE the entire SCRIPT CODE (DDL STATEMENTS) ONTO YOUR PROJECT DESIGN/IMPLEMENTATION DOCUMENT : 1. Requirement #7d GO DO #1: COPY/PASTE all the CONTENT or CREATE TABLE STATEMENTS from the CREATE TABLE script file onto the correct sub-section of requirement #1 of your Design/Implementation Project Document . ❖ Requirement #7e – REQUIREMENT FORMAT & PRESENTATION 1. Requirement #7e GO DO #1: As stated in requirement #1b & #1c , remember to CREATE A PARAGRAPH(S) DESCRIBING THIS SECTION AND WHAT YOU ARE DELIVERING . Also make sure the paragraph is CUSTOMER READY! ❖ Requirement #7f – SAVE & SUBMIT THE PHYSICAL CREATE TABLE SCRIPT FILE #1 WITH YOUR PROJECT DESIGN/IMPLEMENTATION DOCUMENT AS PER REQUIREMENT 11d : 1. Requirement #7f GO DO #1: SAVE your final CREATE TABLE SCRIPT FILE #1 . 2. Requirement #7f GO DO #2: SUBMIT your final CREATE TABLE SCRIPT FILE #1 , along with your Design/Implementation Project Document . 3. Requirement #7f GO DO #3: SEE deliverable section REQUIREMENT #11d of this Project Requirement Document for details on what to submit!!!! TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ Lecture 6B - CST3504 DB Dev with Oracle PART 2 ▪ Book: CST3504 Modern Database Management (Chapter 6)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

199 Requirement #8 (5 POINTS) – ( Phase 4 – DEVELOPMENT/IMPLEMENTATION PHASE: GENARATED SCHEMA DIAGRAM #4 ) – Part 1: GENERATE the Physical Model Schema Diagram Implemented in Requirement #7 from either MS SQL Server DBMS & MS SQL Management Studio (CST4708 class) or Oracle Server DBMS & Oracle SQL Developer (CST3604 class). Part 2: Validate & Compare the GENERATED Physical Model Schema Diagram with the Physical Model Schema Design Diagram of Requirement #6 and verify that what was designed matches what was IMPLEMENTED Database Design Deliverable #7 – Physical Schema Diagram Generation ❑ Generate the implemented Physical Schema Model diagram in MS SQL Server for CST4708 Class & Oracle Server for CST3604 Class as follows: ❖ Requirement #8a – START by READING the instructions in Requirement #1j Section 3 Sub-Section-Header 15 for an overview of the Database Design Deliverable #7 – Implemented Physical Schema Diagram 1. Requirement #8a GO DO #1: Read Requirement #1j Section 2 Sub-Section-Header 15 which describes the Database Design Deliverable #7 – Implemented Physical Schema Diagram . This section provides an overview of REQUIREMENT #8 and descriptions that can help you create the sub-section-header paragraphs for this requirement in addition to other information provided in this requirement. 2. The Implemented Physical Schema Diagram is the Database Developer (that means you!) Comparing & Validating the Physical Schema Design Diagram of REQUIREMENT #6 with the GENERATED Physical Model Schema Diagram of this REQUIREMENT #8 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

200 ❖ Requirement #8b – GENERATE THE DATABASE SCHEMA TABLE DIAGRAM : MS SQL Server (CST4708 CLASS ONLY) 1. Requirement #8b GO DO #1: Using Microsoft SQL Management Studio Admin Tool , GENERATE a table diagram of your schema implementation created in requirement #7 . 2. SEE CST4708 LECTURE 6C for instructions on generating & formatting this diagram using Microsoft SQL Management Studio . 3. This DIAGRAM #4 should contain enough details and information on the entities or tables symbols to be IDENTICAL & MATCH the Physical Model Schema Design Diagram ( Diagram #3 ) of Requirement #6 . ❑ Below is an example of this type of diagram generated from Microsoft SQL Server DBMS via Microsoft SQL Management Studio Admin Tool : TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ Lecture 6C – CST4708_Part3_Implementation ▪ Book: CST3504 Modern Database Management (Chapter 6)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

201 ORACLE Server (CST3604 CLASS ONLY) 1. Requirement #8b GO DO #1: Using Oracle SQL Developer Admin Tool , GENERATE a table diagram of your schema implementation created in requirement #7 . 2. SEE CST3604 LECTURE 6B for instructions on generating & formatting this diagram using Oracle SQL Developer Admin Tool . 3. This DIAGRAM #4 should contain enough details and information on the entities or tables symbols to be IDENTICAL & MATCH the Physical Model Schema Design Diagram ( Diagram #3 ) of Requirement #6 . ❑ Below is an example of this type of diagram generated from Oracle Server DBMS via Oracle SQL Developer Admin Tool : TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found: ▪ My Lectures: ‐ Lecture 6B - CST3504 DB Dev with Oracle PART 2 ▪ Book: CST3504 Modern Database Management (Chapter 6)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

202 For both CST4708 & CST3604 CLASS ❖ Requirement #8c (IMPORTANT STEP!) – COMPARE THIS REQUIREMENT #8 GENERATED PHYSICAL MODEL SCHEMA DIAGRAM TO THE PHYSICAL MODEL SCHEMA DESIGN DIAGRAM OF REQUIREMENT #6 AND VALIDATE THAT EVERY TABLE & RELATIONSHIPS MATCH THE PHYSICAL MODEL SCHEMA DESIGN DIAGRAM OF REQUIREMENT #6 ) : 1. IMPORTANT: o The design & implementation of this DBMS application follows a methodology that executes the following sequence: 1) Based on interviews & discovery activities Gather the Business Requirements . 2) EER Conceptual Model from Business Requirements . 3) Normalized Logical Model from EER Conceptual Model . 4) Physical Model Schema Design Diagram from Normalized Logical Model . 5) Designed & Implemented DBMS Application from Physical Model Schema Design Diagram . 6) Generated Physical Model Schema Diagram from Designed & Implemented DBMS Application . 7) Validation & Testing from Implemented DBMS Application . 8) Engage in Operation & Maintenance from Validation & Testing Results . 2. After acknowledging the above roadmap, shift the focus on the following two steps of the above project management methodology: 5) Designed & Implemented DBMS Application from Physical Model Schema Design Diagram . 6) Generated Physical Model Schema Diagram from Designed & Implemented DBMS Application .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

203 3. The question on this step is as follows: Question: How do you know or validate that your Implemented DBMS Application of Requirement #7 was correctly created FROM the Physical Model Schema Design Diagram of Requirement #6 ? 4. The answer to this question is as follows: Answer: a) Compare the Generated Physical Model Schema Diagram of Requirement #8 to the Physical Model Schema Design Diagram of Requirement #6 . b) This means VALIDATING/COMPARING that every TABLE & RELATIONSHIP in the Generated Physical Model Schema Diagram of Requirement #8 MATCHES every TABLE & RELATIONSHIP in the Physical Model Schema Design Diagram of Requirement #6 and verifying they are the same! c) CST4708 Only – If your Physical Model Schema Design Diagram of Requirement #6 contains 4 Tables and 1 Relationship Lines with Arrows pointing to corresponding tables, then the Generated Physical Model Schema Diagram of Requirement #8 MUST ALSO contains 4 Tables and 1 Relationship Lines with Arrows pointing to corresponding tables. d) CST3604 Only – If If your Physical Model Schema Design Diagram of Requirement #6 contains 13 Tables and 10 Relationship Lines with Arrows pointing to corresponding tables, then the Generated Physical Model Schema Diagram of Requirement #8 MUST ALSO contains 13 Tables and 10 Relationship Lines with Arrows pointing to corresponding tables.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

204 5. Requirement #8c GO DO #1: EXECUTE COMPARISON AND VALIDATE THE RESULTANT SCHEMA IN THE IMPLEMENTED DATABASE MATCHES THE DESIGN OF REQUIREMENT #6 . IF IT DOES NOT MATCH, GO BACK AND REVIEW THE CREATE TABLE STATEMENS OF REQUIREMENT #7 . REPEAT UNTIL GENERATED SCHEMA MATCHES THE DESIGN SCHEMA! THEN MOVE TO THE NEXT STEP! . ❖ Requirement #8d – SAVE THE GENERATED PHYSICAL MODEL SCHEMA DIAGRAM AS AN IMAGE FILE (JPEG, BMP, GIF, OTHER) : 1. Requirement #8d GO DO #1: After validation, follow the instructions from my lecture on this subject to learn how to SAVE this Generated Physical Model Schema Diagram as an IMAGE FILE from such as JPEG , GIF , BMP , etc., and save it to your computer. 2. Requirement #8d GO DO #2: Give it a Name that reflects the project. ❖ Requirement #8e – COPY/PASTE THE SCHEMA DIAGRAM IMAGE FILE ONTO YOUR PROJECT DESIGN/IMPLEMENTATION PROJECT DOCUMENT IN THE CORRECT SUB-HEADER SECTION : 1. Requirement #8e GO DO #1: COPY/PASTE the SCHEMA DIAGRAM IMAGE file onto the appropriate sub-section of your Design/Implementation Project Document . 2. Requirement #8e GO DO #2: Make sure it is pasted to the section identified in requirement #1 . ❖ Requirement #8f – REQUIREMENT FORMAT & PRESENTATION 1. Requirement #8f GO DO #1: As stated in requirement #1b & #1c , remember to CREATE A PARAGRAPH(S) DESCRIBING THIS SECTION AND WHAT YOU ARE DELIVERING . Also make sure the paragraph is CUSTOMER READY! ❖ Requirement #8g – SUBMIT THE ACTUAL SCHEMA DIAGRAM IMAGE FILE WITH YOUR PROJECT DESIGN/IMPLEMENTATION DOCUMENT. SEE REQUIREMENT #11d FOR INSTRUCTION ON SUBMITTING SPRINT #3 : 1. Requirement #8g GO DO #1: SUBMIT your final TABLE SCHEMA DIAGRAM FILE along with your Design/Implementation word document. 2. Requirement #8g GO DO #2: GO TO Requirement #11d , for detailed instructions on what is needed to submit SPRINT #3 and email attachment and subject line information

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

205 Section 5f – Execute Project Management Methodology Validation & Testing Phase SPRINT #4 Requirements #9 ❑ In this section the Database Developer will execute the Validation and Testing Phase and output the required deliverables from this phase as indicated in this requirement. Overview of objectives, activities and deliverables for this phase are shown below: VALIDATION & TEST PHASE – Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

206 Requirement #9 (20 POINTS) – ( Phase 4 – Testing & Validation Phase ) – Via a Script, EXECUTE SQL Data Manipulation Language (DML) SELECT, INSERT, UPDATE & DELETE SQL Statements to Test your database/Tables Using either MS SQL Server DBMS & MS SQL Management Studio (CST4708 class) or Oracle Server DBMS & Oracle SQL Developer (CST3604 class) Database Design Deliverable #8 – Testing & Validation ❑ Test your tables as follows: ❖ Requirement #9a – START by READING the instructions in Requirement #1l Section 3 Sub-Section-Header 16 for an overview of the Database Design Deliverable #8 – Database Validation Unit Testing 1. Requirement #9a GO DO #1: Read Requirement #1l Section 2 Sub-Section-Header 16 which describes the Database Design Deliverable #8 – Database Validation Unit Testing . This section provides an overview of REQUIREMENT #9 and descriptions that can help you create the sub-section- header paragraphs for this requirement in addition to other information provided in this requirement. 2. The Database Validation Unit Testing is the Database Developer (that means you!) Executing SQL Data Manipulation Language (DML) statements such as SELECT , INSERT , UPDATE & DELETE to test the Physical Schema IMPLEMENTED in REQUIREMENT #7 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

207 ❖ Requirement #9b – CREATE A DATA MANIPULATION (DML) SQL TEST QUERIES SCRIPT 1. Requirement #9b GO DO #1: Using Microsoft SQL Management Studio for CST4708 Class or Oracle SQL Developer for CST3604 Class , CREATE A SCRIPT FILE to STORE the TEST QUERIES you will need to execute your schema using DML SQL STATEMENTS (SELECT, INSERT, UPDATE & DELETE) . 2. Requirement #9b GO DO #2: Save & Name the script to file based on your project. ➢ IMPORTANT!!!!! This script file will host/contain ALL DML/ QUERY statements. DO NOT execute a QUERY statement and then delete the QUERY statement from your script after execution and repeating this step thus deleting any history of all the QUERY statements ! This is BAD !! The Script File is to contain ALL the QUERY statements!!! This way you have history of your query statements and can go back and re-execute them as needed . ALL your SCRIPT FILES serve a very important part in the OPERATIONAL/MAINTENANCE PHASE , and that is to be available & ready in the event of a DISASTER/RECOVERY scenario where your physical SERVER COMPUTER is corrupted or damaged and you need to reimplement your entire application in a NEW SERVER COMPUTER . The SCRIPT FILES are used to immediate re-execute the QUERIES, CREATE TABLE STATEMENTS or ANY SERVER-SIDE CODE that needs to be executed to quickly get your database back in production ! ❖ Requirement #9c – DECIDE ON A TABLE GROUP IN YOUR PHYSICAL SCHEMA TO TEST 1. A TABLE GROUP is a subset of the Physical Schema for the entire application that is chosen to be tested. Although for both CST4708 & CST3604 Classes only 13 database tables were implemented as a Pilot , in a real-world scenario, we would be implementing 33 database tables to complete the design . Nevertheless, for the testing, we don’t need to select all tables, just a subset or TABLE GROUP that meet a specific requirement. 2. IMPORTANT – Turns out that for both CST4708 & CST3604 Classes , the 13 database tables that were implemented as a Pilot meet all the requirements of a table group . What this means is that you don’t need to select a TABLE GROUP since the 13 database tables implemented in the Pilot MEET ALL REQUIREMENTS FOR A TABLE GROUP . 3. Nevertheless, for teaching purposes the requirements for identifying a TABLE GROUP within a schema are listed in this section. THE SECTIONS BEYOND THIS POINT ARE UNDER CONSTRUCTION. THEY WILL BE UPDATED SOON.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

208 Guidance on Selecting Your Table Group ❑ After creating and saving your script file, the objectives are that you EXECUTE the DBMS Data Manipulation Language (DML) SQL Statements such as SELECT , INSERT , UPDATE & DELETE statements to TEST a SUBSET of your tables. I will now explain the details requirements on HOW you will go about this. Step 1 – Analyze & Select Table Group (s) ❑ These tests require that you analyze your schema and select table groups as maximize your test. The idea is as follows: ▪ You are not testing ALL tables but selecting a set or group of tables that together represents a BUSINESS SCENARIO . ▪ Once this group is selected, then you will execute the following DML SQL Statements : o SELECT SQL Statements o INSERT SQL Statements o UPDATE SQL Statements o DELETE SQL Statements ❑ You will have to create DML SQL STATEMENTS to tests your database schema. Nevertheless, the following applies: ▪ YOU DO NOT HAVE TO TEST EVERY TABLE ON ENTIRE SCHEMA!!! ONLY A SELECTED TABLES FOR A BUSINESS SCENARIO. THEREFORE, YOU NEED DECIDE ON A TABLE GROUP . ▪ TABLE GROUP REQUIREMENTS – Select a TABLE GROUP based on a business scenario which The TABLE GROUP MUST CONTAIN the following components: 1) At least ONE BINARY (CAN INCLUDE UNARY) RELATIONSHIPS BETWEEN TABLES. 2) At least ONE ASSOCIATIVE TABLE RELATIONSHIP ( 3 or more tables – e.g. Two Parents, one Child or e.g. Three Parents one child etc.) . 3) At least ONE SUPERTYPE/SUBTYPES PARENT WITH MULTIPLE CHILDREN TYPE TABLES if supertype/subtype exists. 4) THERE IS NO LIMITATION AS TO THE NUMBER OF TABLES YOU CAN SELECT FOR A TABLE GROUP ▪ You need to THINK of a business scenario based on your schema or database and put some thoughts on which TABLE GROUP to select based on the requirements listed above.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

209 MS SQL Server (CST4708 CLASS ONLY) ❑ The example below is a chosen TABLE GROUP in MS SQL SERVER DBMS , for a SCHOOL MANAGEMENT SYSTEM APPLICATION Physical Schema Design Model that meets all the requirements for a TABLE GROUP such as: 1. which are ASSOCIATIVE TABLE RELATIONSHIPS between STUDENT , REGISTRATION & SECTION 2. BINARY RELATIONSHIPS between SECTION & COURSE in addition to COURSE & PREREQUISITE 3. and a SUPERTYPE/SUBTYPE structure between STUDENT and its children UNDERGRADUATE & GRADUATE ❑ The TABLE GROUP looks as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

210 Oracle Server (CST3604 CLASS ONLY) ❑ The example below is a chosen TABLE GROUP in ORACLE SERVER DBMS , for a SCHOOL MANAGEMENT SYSTEM APPLICATION Physical Schema Design Model that meets all the requirements for a TABLE GROUP such as: 1. which are ASSOCIATIVE TABLE RELATIONSHIPS between STUDENT , REGISTRATION & SECTION 2. BINARY RELATIONSHIPS between SECTION & COURSE in addition to COURSE & PREREQUISITE 3. and a SUPERTYPE/SUBTYPE structure between STUDENT and its children UNDERGRADUATE & GRADUATE ❑ The TABLE GROUP looks as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

211 For both CST4708 & CST3604 CLASSES ❑ For CST4708 Class & CST3604 Class the current deployment scope of this project, which is a LIMITED PILOT of 13 Tables, already meets the requirements for a TABLE GROUP and is what you will use to TEST your database implementation . ❑ The below 13 Tables will make up the TABLE GROUP you should use to implement your TESTING & VALIDATION :  Note for the USSTATE table requires that you populate this table with 56 states & US regions & the COUNTRY table requires you populate this table with 195 countries.  Importing Data into the USSTATE & the COUNTRY tables: ➢ I will provide in the APPENDIX of this document, an automated process to import from an Excel Worksheet comma-delimited CSV File to the USSTATE & the COUNTRY tables. ➢ I will provide the Excel CSV file with the DATA, and you will EXECUTE the process in the APPENDIX to import to these tables.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

212 ❖ Requirement #9d – RULES THAT YOU NEED TO FOLLOW WHEN POPULATING THE DATABASE TABLES WITH DATA VIA AN SQL DML INSERT STATEMENT AND DECIDING ON THE ORDER OF POPULATING THE TABLES 1. Requirement #9d GO DO #1: Plan & determine the order in which you will populate your table group using SQL DML INSERT STATEMENTS . 2. For both CST4708 & CST3604 Classes only 13 database tables make up your TABLE GROUP . 3. IMPORTANT – These tables need to be POPULATED with DATA/RECORDS/ROWS to perform you testing. In other words, you will need to populate all the tables and add DATA to build your business/test scenario. 4. To do so, you will need to populate the tables using SQL DML INSERT STATEMENTS created inside your TEST SCRIPT FILE and EXECUTE to POPULATE the selected tables in your TABLE GROUP. 5. Nevertheless, you need to PLAN THE ORDER in which you will populate the tables, because of the Foreign Key/Primary Key Relationships between the Tables . 6. In this section, we will analyze how to determine the order of inserts. Rules to Determine the order of inserting records to you tables INSERTION RULE #1 – You CANNOT insert a RECORD to a TABLE that HAS a FOREIGN KEY , WITHOUT FIRST inserting the PARENT TABLE that contains the PRIMARY KEY ❑ Tables that contain a FOREIGN KEY CANNOT BE CREATED before the PARENT TABLE: ▪ What that means is PARENT TABLES FIRST, FOREIGN KEY TABLES LAST! ▪ You cannot try to INSERT a record or row into a table that contains a FOREIGN KEY column BEFORE you have INSERTED the PARENT TABLE with PRIMARY KEY FIRST WITH RECORDS! ▪ Why? Think about it, what values are you going to use for those foreign keys when inserting? Those values MUST ALREADY EXIST! Therefore, those parent tables must be inserted first before you can insert their foreign keys in other tables!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

213 ❑ For example, in the TABLE GROUP shown below: ▪ Suppose you wanted to INSERT a RECORD/ROW to the CUSTOMER table . ▪ As per INSERTION RULE #1 , the CUSTOMER table has 2 FOREING KEYS , DriverLicenseNumberID Foreign Key and CustomerUserAccountID Foreign Key , which means YOU CANNOT INSERT A RECORD INTO CUSTOMER table , UNTIL YOU ALREADY HAVE INSERTED RECORDS to the DRIVERLICENSE table which contains the DriverLicenseNumberID Primary Key and the CUSTOMERUSERACCOUNT table which contains the CustomerUserAccountID Primary Key . ▪ Therefore, the DRIVERLINCENSE & CUSTOMERUSERACCOUNT TABLES HAVE TO BE INSERTED FIRST BEFORE YOU CAN INSERT TO THE CUSTOMER TABLE as shown below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

214 INSERTION RULE #2 – Based on Rule #1, PLAN the ORDER to insert your Tables in the TABLE GROUP before performing any INSERTS! ❑ PLAN THE ORDER OF INSERTION BEFORE INSERTING: ▪ Based on the thought process of Rule #1 in mind, you need to plan the order of your insertion in your TABLE GROUP. ▪ for the table group in my example in PART 1 above, I would use the following ORDER to insert records into the table. ❑ For example, in the TABLE GROUP shown below: ▪ A possible ORDER OF INSERTION for all the tables in the table group is shown based on PRIMARY KEY to FOREIGN KEY relationships :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

215 INSERTION RULE #3 (Extension of Rule #1 & Rule #2) – PLAN & SELECT the VALUES OF THE INSERT STATEMENTS in ADVANCE so your testing MAKES BUSINESS SENSE! This also involves the ORDER of INSERTION RULES #1 & RULES #2! ❑ PLAN THE VALUES YOU WILL ENTER IN THE INSERT STATEMENT BEFORE INSERTING: ▪ You need to think and plan the actual values of the records you plan to INSERT as you build your Business Scenario for testing! ▪ As per Rule #1 , when you INSERT records to PARENT TABLES whose PRIMARY KEYS are FOREIGN KEYS in other tables, such as the DRIVERLICENSE table and CUSTOMERUSERACCOUNT table, both which have FOREIGN KEYS in the CUSTOMER table , select VALUES which will make your testing scenarios make business sense and be an effective test. ❑ ASSOCIATE TABLES are good examples of this planning. ❑ For example, look at the TABLE GROUP and lets FOCUS on the ORDER OF INSERTION for the ASSOCIATIVE TABLE CUSTOMER_CREDITCARD shown below:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

216 ❑ Analysis of how and why to plan & the VALUES you need to insert to the ASSOCIATIVE TABLE CUSTOMER_CREDITCARD : ▪ The ASSOCIATIVE TABLE CUSTOMER_CREDITCARD has two Foreign Keys , the CreditCardNumber which is a Foreign Key to the CREDITCARD table Primary Key CreditCardNumber , and the CustomerID which is a Foreign Key to the CUSTOMER table CustomerID . ▪ Together both these Foreign Keys CreditCardNumber and CustomerID combine are the COMPOSITE PRIMARY KEY of the CUSTOMER_CREDITCARD table! ▪ As per Rule #1 , you CANNOT INSERT into the ASSOCIATIVE TABLE CUSTOMER_CREDITCARD table until you have INSERTED RECORDS into both the CREDITCARD TABLE and the CUSTOMER TABLE FIRST!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

217 ▪ So here is the POINT of Rule #3 : o When you decide to INSERT RECORDS into both the CREDITCARD TABLE and the CUSTOMER TABLE , you need to THINK ABOUT THE VALUES of these RECORDS ahead of time, so the testing environment makes business sense . o For example, you will want to INSERT FIRST the CUSTOMER Record who OWNS that specific Credit Card(s) FIRST then the MATCHING CREDITCARD Record before you can INSERT a CUSTOMER_CREDITCARD Record to indicate the Credit Card is owned by the Customer! o There are three business scenarios in between a Customer & the Credit Card(s) OWNED by a Customer based on the business requirements which state “A Customer can own many Credit Cards and a Credit Card can be owned by many Customers” , which is a MANY- TO-MANY RELATIONSHIP between CUSTOMER Table & CREDITCARD Table . o The 3 scenarios are as follows: 1) Scenario #1 – A Customer OWNS only ONE Credit Card . 2) Scenario #2 – A Customer OWNS MANY Credit Cards . 3) Scenario #3 – A Credit Card is OWNED by MANY Customers . o These are the 3 scenarios you are targeting to test since these are the scenarios that will occur in this business. ❑ Let’s look at each of these scenarios in detail: ▪ Scenario #1 – A Customer OWNS only ONE Credit Card : o In this scenario #1 , you would need to: 1) INSERT ONE RECORDS into the CUSTOMER TABLE , which represents the Customer who OWNS the ONE Credit Card . 2) INSERT ONE RECORDS into the CREDITCARD TABLE , which represents the ONE Credit Card OWNED by the ONE Customer . 3) Finally, now you can INSERT ONE RECORDS into the CUSTOMER_CREDITCARD TABLE , which STORES the ONE RECORD that indicates the Credit Card OWNED by the ONE Customer via the combination of the two Foreign Keys ( CustomerID & CreditCardNumber ) that make up the UNIQUE COMPOSITE PRIMARY KEY .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

218 ▪ Scenario #2 – A Customer OWNS MANY Credit Cards : o In this scenario #2 , you would need to: 1) INSERT ONE RECORDS into the CUSTOMER TABLE , which represents the Customer who OWNS the MANY Credit Cards . 2) INSERT MANY RECORDS AS DESIRED into the CREDITCARD TABLE , which represents the MANY Credit Cards OWNED by the ONE Customer . 3) Finally, now you can INSERT MANY RECORDS into the CUSTOMER_CREDITCARD TABLE , which STORES the MANY RECORDS , one for each Credit Card OWNED by the ONE Customer via the combination of the two Foreign Keys ( CustomerID & CreditCardNumber ) that make up the UNIQUE COMPOSITE PRIMARY KEY for EACH OWNED Credit Card . ▪ Scenario #3 – A Credit Card is OWNED by MANY Customers : o In this scenario #3 , you would need to: 1) INSERT MANY RECORDS into the CUSTOMER TABLE , which represents the Customers who will OWN & SHARE ONE Credit Card . 2) INSERT ONE RECORD into the CREDITCARD TABLE , which represents the ONE Credit Card OWNED by the MANY Customers created in step 1 . 3) Finally, now you can INSERT THE 2 OR MANY RECORDS into the CUSTOMER_CREDITCARD TABLE , which STORES the THE 2 OR MANY RECORDS , one for each Credit Card OWNED by EACH Customer via the combination of the two Foreign Keys ( CustomerID & CreditCardNumber ) that make up the UNIQUE COMPOSITE PRIMARY KEY for EACH OWNED Credit Card .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

219 ❖ Requirement #9e (5 POINTS) – Create INSERT statements to POPULATE your chosen TABLES from your TABLE GROUP : ❑ In your TEST SCRIPT FILE , create DML SQL INSERT STATEMENTS to POPULATE the selected TABLE GROUP by executing the following requirements: ▪ Requirement #9e-1a ( Requirement #9e-1a GO DO #1 ) – INSERT STATEMENTS (#1 - #5 ) – Create INSERT Statements that inserts all fields/columns to a minimum of FIVE RECORDS into THE FIRST TABLE OF YOUR CHOSEN TABLE GROUP THAT MUST BE A PARENT #1 TO AN ASSOCIATIVE CHILD TABLE . NOTE, THIS TABLE SHOULD NOT BE THE ASSOCIATIVE CHILD TABLE ITSELF BUT ONE OF IT’S PARENT ! ▪ For example, in the School Management System Table Group example, the below snapshot shows this scenario of Two Parent tables with Associate Child Table, which include: 1) PARENT 1 – STUDENT table (with StudentID Primary Key) 2) PARENT 2 – SECTION table (with SectionID Primary Key) 3) CHILD – REGISTRATION table (with COMPOSITE KEY composed of StudentID Foreign Key & SectionID Foreign Key which combined become the composite Primary key of the REGISTRATION table) ▪ Note the order or numbering for a parent does not matter. I chose STUDENT as PARENT #1 but I could have chosen the SECTION table as PARENT #1. ▪ Below is a snapshot of this scenario and target table for the first 5 inserts for CST4708 Class & MS SQL Server and CST3604 Class & ORACLE Server :

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

220 ▪ Example of Target Parent #1 Table to insert CST4708 Class – MS SQL Server ▪ Example of Target Parent #1 Table to insert CST3604 Class – ORACLE Server

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

221 ▪ Requirement #9e-1b ( Requirement #9e-1b GO DO #1 ) – Values of records inserted must be planned and NOT Radom: o Keep in mind that before you insert the 5 records into this PARENT table via the INSERT Statements that you have already EXECUTED Requirement #9d and PLANNED YOUR CODE AND SCENARIOS ahead of time so the records that you are adding will match your scenarios. o For example, in Requirement #9d RULE #3 (PLAN YOUR INSERTS) , we discussed the following CREDITCARD (Parent #1), CUSTOMER (Parent #2) & CUSTOMER_CREDITCARD (Parent #3) scenario: o In this scenario, the learned that There are three business scenarios between a Customer & the Credit Card(s) OWNED by a Customer based on the business requirements which state “A Customer can own many Credit Cards and a Credit Card can be owned by many Customers” , which is a MANY-TO-MANY RELATIONSHIP between CUSTOMER Table & CREDITCARD Table , which results in the following 3 scenario: a) Scenario #1 – A Customer OWNS only ONE Credit Card . b) Scenario #2 – A Customer OWNS MANY Credit Cards . c) Scenario #3 – A Credit Card is OWNED by MANY Customers . o THE POINT HERE ARE AS FOLLOWS : - Before you INSERT your RECORDS to this PARENT #1 table , make sure you have already planned the values in those records prior to the insertion so that they will MATCH the other PARENT #2 table & ASSOCIATE CHILD Table values that will proof the 3 business scenarios . - In other words, YOU ARE NOT JUST ADDING RAMDOM VALUES TO THE RECORDS BEING INSERTED to the CREDITCARD Table , CUSTOMER Table & CUSTOMER_CREDITCARD Table , but VALUES that you INSERT must prove the 3 business scenarios shown Requirement #9d !

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

222 ▪ Requirement #9e-1c ( Requirement #9e-1c GO DO #1 ) – Create & Execute the Insert Statements to Populate this Parent #1 Table: o In this Requirement #9e-1c , you are to plan, create, execute & troubleshoot the Insert Statements to populate this Parent #1 table as described below. 1) In the SCRIPT FILE, Plan , Design , Create & Execute the first SQL INSERT Statement for this table . 2) Only after you troubleshoot & successfully executed the query, go to the next step . 3) In the SCRIPT FILE, Design , Create & Execute second SQL INSERT Statement for this table . 4) Only after you troubleshoot & successfully executed the query, go to the next step . 5) REPEAT steps 2 through 4 until all FIVE or MORE SQL INSERT Statements have been executed . 6) Only after you have troubleshooted & successfully executed ALL the FIVE or MORE INSERT Statements, have you completed the insertion to this table .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

223 ▪ Requirement #9e-1d ( Requirement #9e-1e GO DO #1 ) – Document Content & Format Requirements in Database Validation Testing Sub-Section : o For this Requirement #9e-1a, 1b & 1c , the information & format that you will need to follow is described below. o Requirement #9e-1d GO DO #1: Inside the Database Validation Testing Sub- Heading section of Requirement #1 of your DESIGN & IMPLEMENTATION PROJECT DOCUMENT do the following: a) CREATE a SMALL-SECTION-HEADER describing the TABLE you executed the insert statements . Note that the size of this section header should use smaller font size than the Database Validation Testing SUB-HEADER . b) ADD a short paragraph explaining what table you are inserting ( Requirement 1b ) and make sure is customer ready ( Requirement 1c ) c) ADD another short/single line/paragraph stating the BEFORE/CURRENT state of the table that is about to be populated. d) ADD the listing of the SELECT * FROM table SQL statement that will be used to display the content of the table. e) TAKE a SCREENSHOT of the results of the execution of the SELECT * FROM table SQL statement in MS SQL SERVER for CST4708 Class and ORACLE Server for CST3604 Class and COPY/PASTE here. f) ADD another short/single line/paragraph describing that you are about to list all the SQL INSERT STATEMENTS that were executed on the table. g) From the SCRIPT , COPY/PASTE ALL the SQL INSERT STATEMENTS that were executed on the PARENT 1 Table to here. h) ADD another short/single line/paragraph stating the SELECT SQL statement that is used to list the table AFTER the execution of the SQL INSERT STATEMENTS . i) ADD the actual listing of the SELECT * FROM table SQL statement that is used to display the content of the table. j) TAKE a SCREENSHOT of the results of the execution of the SELECT * FROM table SQL statement in MS SQL SERVER for CST4708 Class and ORACLE Server for CST3604 Class showing the PROOF that the SQL INSERT STATEMENTS were successful and populated the Table with the exact records inserted and COPY/PASTE here. o Below is a snapshot of what the above steps should look like in your document:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

224 o You are now done with this Requirement #9e-1a, 1b & 1c .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

225 ▪ Requirement #9e-2 ( Requirement #9e-2 GO DO #1 ) – INSERT STATEMENTS (#6 - #10) – Create INSERT Statements that inserts all fields/columns to a minimum of FIVE RECORDS into THE SECOND TABLE OF YOUR CHOSEN TABLE GROUP THAT MUST BE A PARENT #2 TO AN ASSOCIATIVE CHILD TABLE . NOTE, THIS TABLE SHOULD NOT BE A SUPERTYPE PARENT TABLE OR THE ASSOCIATIVE CHILD TABLE ! For example, in this requirement you can select SECTION as PARENT #2 or second table since you selected STUDENT as PARENT #1 in previous insert statements. 1) Requirement #9e-2 GO DO #2: IMPORTANT! – AFTER THE PREVIOUS INSERT TABLE STATEMENTS AND RESULTS, IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this grouping of insert statements you are about to execute. b) Add a short paragraph/Label describing the insert statements you are executing. c) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! d) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT proving the table is empty. 2) In the SCRIPT FILE, Design , Create & Execute the first SQL INSERT Statement for this table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) In the SCRIPT FILE, Design , Create & Execute second SQL INSERT Statement for this table . 5) Only after you troubleshoot & successfully executed the query, go to next step . 6) REPEAT steps 2 through 5 until all SQL INSERT Statements have been executed . 7) Only after you troubleshoot & successfully executed ALL the INSERT Statements/ query(s), go to next step . 8) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE ALL THE WORKING INSERT statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of all the INSERTIONS to the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

226 ▪ Example of Target Parent #2 Table to insert ▪ Example of Target Parent #2 Table to insert

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

227 ▪ Requirement #9e-3( Requirement #9e-3 GO DO #1 ) – INSERT STATEMENTS (#11 - #15) – Create INSERT Statements that inserts all fields/columns to a minimum of FIVE RECORDS into THE ASSOCIATIVE CHILD TABLE OF YOUR CHOSEN TABLES TABLE GROUP. For example, in my Table Group, STUDENT & SECTION are PARENTS tables and were populated with data in Requirements #9c-1 & #9c-2, therefore now we select the REGISTRATION ASSOCIATIVE CHILD TABLE to insert records to complete our business scenario between the PARENTS & ASSOCIATIVE CHILD TABLES. ‐ IMPORTANT! – For the ASSOCIATIVE CHILD TABLE , the FOREIGN KEY(S)/COMPOSITE KEY(S) DATA YOU ARE INSERTING MUST MATCH/ALIGN WITH PRIMARY KEY DATA EXISTING IN THE TWO PARENT TABLES for it to make business sense . In other words, FOREIGN-KEYS MUST MATCH PRIMARY KEYS of parent tables. 1) Requirement #9e-3 GO DO #2: IMPORTANT! – AFTER THE PREVIOUS INSERT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9C-2 , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this grouping of insert statements you are about to execute. b) Add a short paragraph/Label describing the insert statements you are executing. c) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! d) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT proving the table is empty. 2) In the SCRIPT FILE, Design , Create & Execute the first SQL INSERT Statement for this table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) In the SCRIPT FILE, Design , Create & Execute second SQL INSERT Statement for this table . 5) Only after you troubleshoot & successfully executed the query, go to next step . 6) REPEAT steps 2 through 5 until all SQL INSERT Statements have been executed . 7) Only after you troubleshoot & successfully executed ALL the INSERT Statements/ query(s), go to next step . 8) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE ALL THE WORKING INSERT statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of all the INSERTIONS to the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

228 ▪ Example of Target Associative Child #3 Table to insert ▪ Example of Target Associative Child #3 Table to insert

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

229 ▪ Requirement #9c-4( Requirement #9e-4 GO DO #1: ) – INSERT STATEMENTS (#15 - #35? ) – Create INSERT Statements that inserts all fields/columns to A SUPERTYPE/SUBTYPES TABLE STRUCTURE COMPOSED OF SUPERTYPE PARENT TABLE & SUBTYPE CHILD TABLES . For example, in my Table Group in previous page, STUDENT is a SUPERTYPE TABLE FOR SUBTYPES UNDERGRADUATE & GRADUATE TABLES . This means all three tables STUDENT , UNDERGRADUATE & GRADUATE TABLES are the targets of this requirements. Note that in my example scenario, the STUDENT TABLE was also used for the previous INSERT STATEMENTS as part of the STUDENT & SECTION PARENTS to the REGISTRATION ASSOCIATIVE CHILD TABLE , which means in this case STUDENT TABLE is already created. This is just a coincidence of my example, other scenarios can be different. To do this requirement, fist INSERT the required number of ROWS into SUPERTYPE PARENT TABLE & then to its designated SUBTYPE CHILD TABLES to complete your business scenario. INSERT a minimum of FIVE ROW/RECORDS into each SUBTYPE CHILD TABLE & the required number of ROWS into the SUPERTYPE PARENT TABLE that map to EACH SUBTYPE CHILD TABLE. To calculate the number of rows required in the SUPERTYPE PARENT TABLE, is as follows: ‐ IMPORTANT! – THE NUMBER OF ROWS TO INSERT INTO A SUPERTYPE PARENT OF A SUPERTYPE/SUBTYPES TABLE STRUCTURE IS THE SUM OF THE NUMBER OF ROWS IN EACH CHILD SUBTYPES TABLE . ‐ Recall that a COMPLETE RECORD OR ROW IN A SUPERTYPE/SUBTYPES TABLE STRUCTURE IS A COMBINATION OF THE SUPERTYPE PARENT ROW/RECORD AND ITS DESIGNATED CHILD SUBTYPE RECORDS. So, for example, if the CHILD #1 SUBTYPE TABLE require 5 ROWS , then the SUPERTYPE PARENT TABLE MUST HAVE 5 ROWS to match the 5 ROWS of CHILD #1 SUBTYPE , and if the OTHER CHILD #2 SUBTYPE has 5 ROWS then the SUPERTYPE PARENT TABLE MUST HAVE ANOTHER 5 ROWS to match the 5 ROWS of CHILD #2 SUBTYPE , for a TOTAL of 10 ROWS for the SUPERTYPE/SUBTYPES TABLE . ‐ What’s the Point? You will need to INSERT in the SUPERTYPE PARENT the SUM of all the ROWS/RECORDS of ALL the SUBTYPES ROWS/RECORDS. IF EACH CHILD REQUIRES 5 ROWS , THEN THE PARENT MUST HAVE 10 ROWS , 5 FOR EACH CHILD! 1) Requirement #9e-4 GO DO #2: IMPORTANT! – AFTER THE INSERT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9C-3 , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this grouping of insert statements you are about to execute. b) Add a short paragraph/Label describing the insert statements you are executing. c) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! d) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT proving the table is empty.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

230 2) In the SCRIPT FILE, Design , Create & Execute the first SQL INSERT Statement for the SUPERTYPE PARENT TABLE . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) In the SCRIPT FILE, Design , Create & Execute the first SQL INSERT Statement for the SUBTYPE CHILD TABLE that MATCH the first SUPERTYPE PARENT TABLE inserted in step 2) . 5) Only after you troubleshoot & successfully executed the query, go to next step . 6) In the SCRIPT FILE, Design , Create & Execute second SQL INSERT Statement for the SUPERTYPE PARENT TABLE . 7) Only after you troubleshoot & successfully executed the query, go to next step . 8) REPEAT steps 2 through 7 until all SQL INSERT Statements have been executed for the SUPERTYPE/SUBTYPES TABLE STRUCTURE COMPOSED OF SUPERTYPE PARENT TABLE & SUBTYPE CHILD TABLES . REMEMBER that the SUPERTYPE PARENT TABLE number of ROWS = NumberChild1Rows + NumberChild2Rows + NumberChild(N)Rows , therefore calculate the number or ROWS you need in the PARENT table based on the number of child records you need in the CHILD tables so you can determine how may INSERT Statements you need for the SUPERTYPE PARENT TABLE. 9) Only after you troubleshoot & successfully executed ALL the INSERT Statements/ query(s) for the SUPERTYPE PARENT & CHILD TABLES , go to next step . 10) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE ALL THE WORKING INSERT statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of all the INSERTIONS to the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT. ▪ Example of Target First Supertype Parent Table to insert ▪ Note that this table may already have rows from previous insert operations ▪ Example of Target Subtype Child #1 Table to insert ▪ Note inserted row must match a Supertype Parent record. ▪ Example of Target Subtype Child #2 Table to insert ▪ Note inserted row must match a Supertype Parent record.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

231 ▪ Requirement #9e-5( Requirement #9e-5 GO DO #1 ) – REPEAT INSERT STATEMENTS – repeat the above steps for any additional tables that are part of your TABLE GROUP. TO UNDERSTAND HOW TO SOLVE THIS REQUIREMENT, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found in my CST3504 Lecture: ‐ Lecture 6D – CST4708_DB_Part3_Database_Development ‐ In this lecture you will see examples of each of these types of queries! ▪ Example of Target First Supertype Parent Table to insert ▪ Note that this table may already have rows from previous insert operations ▪ Example of Target Subtype Child #1 Table to insert ▪ Note inserted row must match a Supertype Parent record. ▪ Example of Target Subtype Child #2 Table to insert ▪ Note inserted row must match a Supertype Parent record.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

232 ❖ Requirement #9f (5 POINTS) – Create SELECT statements to RETURN RECORD(S) from your chosen TABLE from your TABLE GROUP : ❑ In your TEST SCRIPT FILE , create DML SQL SELECT STATEMENTS to TEST the schema as follows: ▪ Requirement #9f-1( Requirement #9f-1 GO DO #1 ) – SELECT STATEMENT #1 – Create SELECT Statements that queries ONE TABLE of the CHOSEN TABLE GROUP RETURNING ONLY ONE RECORD THAT INCLUDES ALL COLUMNS BASED ON PRIMARY KEY . 1) Requirement #9f-1 GO DO #2: In the SCRIPT FILE, Design , Create & Execute SQL SELECT Statement . 2) Only after you troubleshoot & successfully executed the query(s), go to next steps 3) IMPORTANT! – AFTER THE SELECT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9C , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) Create a SUB-HEADING for this SELECT STATEMENT. b) Add a short paragraph/Label describing the query you execute. c) COPY/PASTE the SELECT QUERY just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . d) Add a short paragraph/Label describing the RESULTS of query execution. e) COPY/PASTE a SCREEN-SHOT of the RESULTS of SELECT query as proof of execution. ▪ Requirement #9f-2( Requirement #9f-2 GO DO #1 ) – SELECT STATEMENT #2 – Create SELECT Statements that queries ONE TABLE of the CHOSEN TABLE GROUP RETURNING MULTIPLE RECORDS THAT INCLUDES ALL COLUMNS BASED ON BASED ON SOME CRITERIA OTHER THAN PRIMARY KEY ALONE. CRITERIA CAN INCLUDE PRIMARY KEY BUT IT MUST ALSO INCLUDE OTHER FILTERS OR CRITERIAS . 1) Requirement #9f-2 GO DO #2: In the SCRIPT FILE, Design , Create & Execute SQL SELECT Statement . 2) Only after you troubleshoot & successfully executed the query(s), go to next steps 3) IMPORTANT! – AFTER THE SELECT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9d-1 , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) Create a SUB-HEADING for this SELECT STATEMENT. b) Add a short paragraph/Label describing the query you execute. c) COPY/PASTE the SELECT QUERY just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . d) Add a short paragraph/Label describing the RESULTS of query execution. e) COPY/PASTE a SCREEN-SHOT of the RESULTS of SELECT query as proof of execution. TO UNDERSTAND HOW TO SOLVE REQUIREMENT 9, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found in my CST3504 Lecture: ‐ Lecture 6D – CST3504-DB Dev with Oracle PART3 ‐ In this lecture you will see examples of each of these types of queries!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

233 ▪ Requirement #9f-3( Requirement #9f-3 GO DO #1 ) – SELECT STATEMENT #3 – Create SELECT Statements that queries THREE of the CHOSEN TABLE GROUP THAT ARE PART OF AN ASSOCIATIVE ENTITY SET (PARENT1, PARENT2 & ASSOCIATIVE CHILD TABLE) RETURNING ONE OR MULTIPLE RECORDS THAT INCLUDES ONE OR MULTIPLE COLUMNS FROM EACH OF THE THREE TABLE BASED ON A CRITERIA FOR SOME BUSINESS SCENARIO. Below is a description and example of this type of query: ‐ In the table group example of Requirement #9b on page 54 , the tables STUDENT , STUDENT_REGISTRATION & SECTION tables are examples of THREE CHOSEN TABLE , that make up a an associative entity set of PARENT1, PARENT2 & ASSOCIATIVE CHILD TABLE where STUDENT & SECTION tables are the PARENTS and STUDENT_REGISTRATION table is the CHILD ASSOCIATIVE ENTITY ! ‐ We could create a query that requires ALL THREE TABLES to participate in order to solve a business request or report. ‐ For example, supposed the business needs the studentID , name , address , majo r , sectionID , courseID , semester & year of the student whose studentID = 1111 . This query requires all three tables PARENT1, PARENT2 & ASSOCIATIVE CHILD TABLE) to be accessed together in order to return the 8 COLUMNS required to satisfy this business report. 1) Requirement #9f-3 GO DO #2: In the SCRIPT FILE, Design , Create & Execute SQL SELECT Statement . 2) Only after you troubleshoot & successfully executed the query(s), go to next steps 3) IMPORTANT! – AFTER THE SELECT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9C , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) Create a SUB-HEADING for this SELECT STATEMENT. b) Add a short paragraph/Label describing the query you execute. c) COPY/PASTE the SELECT QUERY just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . d) Add a short paragraph/Label describing the RESULTS of query execution. e) COPY/PASTE a SCREEN-SHOT of the RESULTS of SELECT query as proof of execution. TO UNDERSTAND HOW TO SOLVE REQUIREMENT 9, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found in my CST3504 Lecture: ‐ Lecture 6D – CST3504-DB Dev with Oracle PART3 ‐ In this lecture you will see examples of each of these types of queries! ▪ All Three Tables (Two parents & Associative Child) are JOINED & required for this SELECT query Statement

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

234 ❖ Requirement #9g (5 POINTS) – Create UPDATE statements to UPDATE RECORD(S) your chosen TABLE from your TABLE GROUP : ❑ In your TEST SCRIPT FILE , create DML SQL UPDATE STATEMENTS to TEST the schema as follows: ▪ Requirement #9g-1( Requirement #9g-1 GO DO #1 ) – UPDATE STATEMENT #1 – Create UPDATE Statements that UPDATES ONE RECORD OF A PARENT TO AN ASSOCIATIVE CHILD TABLE OF THE CHOSEN TABLE GROUP . NOTE THIS TABLE SHOULD NOT BE THE ASSOCIATIVE CHILD TABLE BUT ONE OF ITS PARENT ! For example, in my Table Group STUDENT & SECTION are PARENTS tables to ASSOCIATIVE CHILD TABLE REGISTRATION so you can select STUDENT or SECTION to UPDATE. YOU ARE TO UPDATE ALL COLUMNS EXCEPT THE PRIMARY KEY . 1) Requirement #9g-1 GO DO #2: IMPORTANT! – AFTER THE SELECT TABLE STATEMENTS AND RESULTS OF REQUIREMENT #9D , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this UPDATE statement you are about to execute. b) Add a short paragraph/Label describing the UPDATE statement you are executing. c) CHOSE the Table to perform the UPDATE. d) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! e) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT showing the CONTENT of the table. 2) In the SCRIPT FILE, Design , Create & Execute the first SQL UPDATE Statement for selected table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE THE WORKING UPDATE statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of the UPDATE statements EXECUTED on the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT. ▪ Either of these Parent Tables are candidate for this Update Statement

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

235 ▪ Requirement #9g-2( Requirement #9g-2 GO DO #1 ) – UPDATE STATEMENT #2 – Create UPDATE Statements that UPDATES ONE RECORD OF AN ASSOCIATIVE CHILD TABLE OF THE CHOSEN TABLE GROUP . NOTE THIS TABLE SHOULD NOT BE THE PARENT TABLE , BUT THE ASSOCIATIVE CHILD TABLE ! For example, in my Table Group STUDENT & SECTION are PARENTS tables to ASSOCIATIVE CHILD TABLE REGISTRATION in this case, select REGISTRATION TABLE to UPDATE. YOU ARE TO UPDATE ONE OR MORE COLUMNS OF YOUR CHOICE, WHICH CAN INCLUDE THE PRIMARY KEY, COMPOSITE KEY OR OTHER. 1) Requirement #9g-2 GO DO #2: IMPORTANT! – AFTER THE UPDATE TABLE STATEMENT AND RESULTS OF REQUIREMENT #9e-1 , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this UPDATE statement you are about to execute. b) Add a short paragraph/Label describing the UPDATE statement you are executing. c) CHOSE the Table to perform the UPDATE. d) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! e) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT showing the CONTENT of the table. 2) In the SCRIPT FILE, Design , Create & Execute the second SQL UPDATE Statement for selected table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE THE WORKING UPDATE statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of the UPDATE statements EXECUTED on the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT. TO UNDERSTAND HOW TO SOLVE REQUIREMENT 9, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found in my CST3504 Lecture: ‐ Lecture 6D – CST3504-DB Dev with Oracle PART3 ‐ In this lecture you will see examples of each of these types of queries! ▪ This table is target of this Update Statement

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

236 ❖ Requirement #9h (5 POINTS) – Create DELETE statements to DELETE RECORD(S) from you chosen TABLE from your TABLE GROUP : ❑ In your TEST SCRIPT FILE , create DML SQL DELETE STATEMENTS to TEST the schema as follows: ▪ Requirement #9h-1( Requirement #9h-1 GO DO #1 ) – DELETE STATEMENT #1 – Create DELETE Statements that DELETES ONE RECORD BASED ON THE PRIMARY KEY OF ONE OF THE TABLE OF YOUR CHOSEN TABLE GROUP THAT IS NOT AN ASSOCIATIVE ENTITY , IMPORTANT : IF YOU ARE NOT ALLOW TO DELETE DUE TO A DEPENDENCIES OR FOREIGN KEYS CONSTRAINT, TAKE THE NECESSARY STEPS REQUIRED THAT WILL ALLOW YOU TO DELETE THE RECORD & PROVIDE OVERVIEW OF THE STEPS REQUIRED TO DELETE THE ROW. ‐ In this case, we have another scenario that depends on the CHOSEN TABLE GROUP & SCHEMA . ‐ It could be the case, that the record in a table that you are trying to delete, MAY HAVE DEPENDENCIES OR FOREIGN KEYS FROM OTHER TABLES BASED ON RELATIONSHIPS AND YOU CANNOT DELETE THE RECORD . Therefore, in this case you need to take the necessary steps to be able to DELETE this record. I am not telling you what those steps are since I want you to think, but it may require modifications of other tables! ‐ In this case, you MUST DOCUMENT THE STEPS YOU TOOK TO DELETE THIS RECORD in your PROJECT DOCUMENT . ‐ OR it could be the case there are NO DEPENDENCIES AND YOU ARE ABLE TO SIMPLY DELETE THE RECORD WITH NO ADDITIONAL STEPS REQUIRED ! 1) Requirement #9h-1 GO DO #2: IMPORTANT! – AFTER THE UPDATE TABLE STATEMENT AND RESULTS OF REQUIREMENT #9e , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this DELETE statement you are about to execute. b) Add a short paragraph/Label describing the DELETE statement you are executing. c) CHOSE the Table to perform the DELETE. d) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! e) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT showing the CONTENT of the table. 2) In the SCRIPT FILE, Design , Create & Execute the first SQL DELETE Statement for selected table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE THE WORKING DELETE statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of the DELETE statements EXECUTED on the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

237 ▪ Requirement #9h-2( Requirement #9h-2 GO DO #1 ) – DELETE STATEMENT #2 – Create DELETE Statements that DELETES ONE RECORD OF AN ASSOCIATIVE ENTITY TABLE of your CHOSEN TABLE GROUP . 1) Requirement #9h-2 GO DO #2: IMPORTANT! – AFTER THE DELETE TABLE STATEMENT AND RESULTS OF REQUIREMENT #9f-1 , IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT DO THE FOLLOWING: a) CREATE ANOTHER SUB-HEADING for this DELETE statement you are about to execute. b) Add a short paragraph/Label describing the DELETE statement you are executing. c) CHOSE the Table to perform the DELETE. d) In the script, use a SELECT * FROM TABLE query to display the current content or state of this table. The results should be an empty Table! e) Take a SCREEN-SHOT of the results & COPY/PASTE to the IMPLEMENTATION PROJECT DOCUMENT showing the CONTENT of the table. 2) In the SCRIPT FILE, Design , Create & Execute the second SQL DELETE Statement for selected table . 3) Only after you troubleshoot & successfully executed the query, go to next step . 4) IMPORTANT! – IN THE DESIGN & IMPLEMENTATION PROJECT DOCUMENT in the same section DO THE FOLLOWING: a) COPY/PASTE THE WORKING DELETE statements just executed in the script to the document. DO NOT use a screenshot, it should be formatted text like in your script . b) Add a short paragraph/Label describing the RESULTS of query execution. c) In the script, use a SELECT * FROM TABLE query to display results of the DELETE statements EXECUTED on the table and take a SCREEN-SHOT of the results & COPY/PASTE to the DOCUMENT. TO UNDERSTAND HOW TO SOLVE REQUIREMENT 9, GO FISHING! HERE IS WHERE: Theory & Examples on this TOPIC can be found in my CST3504 Lecture: ‐ Lecture 6D – CST3504-DB Dev with Oracle PART3 ‐ In this lecture you will see examples of each of these types of queries!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

238 Section 5g – Execute Project Management Methodology Operation Phase SPRINT #4 Requirements #10 ❑ In this section the job of the Database Developer is concluded and is now the Database Administrator & Other IT Professionals such as Server Engineering Team, Security etc., that take ownership of the Operations & Maintenance Phase and output the requires deliverable from this phase as indicated in this requirement. ❑ Note that the Database Architect and Database Developer will re-engage when an upgrade to the DBMS Server Application is required, and the entire development methodology is repeated. ❑ Overview of objectives, activities and deliverables for this phase are shown below: OPERATIONS & MAINTENANCE PHASE – Short description, activities & deliverables are as follows:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

239 Requirement #10 (0 POINTS) – ( Phase 6 – OPARATIONS & MAINTENANCE PHASE ) – Maintain & Operate the Implemented Database Application ❑ NO ACTION IS REQUIRED IN THIS PHASE FOR DATABASE DEVELOPER: ▪ The Database Administrator (DBA) will run the day-to-day activities of operating the DBMS. ▪ You will recall back if upgrade is required. ❑ In the next set of projects in both CST4708 Class and CST3604 class, you will return to implement new features so OPERATE & MAINTAIN YOUR LAB ENVIRONMENT SO IT IS READY FOR NEXT PROJECT!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

240 Section 6 – Project 1 Deliverables (** This Section Lists WHAT Exactly you need Submit for this Project and HOW to submit & WHEN! FOLLOW THESE REQUIREMENTS/STEPS EXACTLY AS INDICATED TO SUBMIT YOUR PROJECT!**) Section 6a – Project Deliverables (What you are Submitting which is ALL SPRINTS together) SPRINT #1, SPRINT #2, SPRINT #3 & SPRINT #4 ❑ This section contains the requirements for submitting the projects as follows: 1. Submitting by SPRINT – SPRINT #1, SPRINT #2, & SPRINT #3 only. 2. Submitting the LAST SPRINT #4 – the sum of ALL SPRINTS (SPRINT #1, SPRINT #2, & SPRINT #3). ❑ Pay close attention to the details of this section or you will lose unnecessary points.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

241 Requirement #11 (5 POINTS) – Project Timelines & Expected Deliverable Requirements) ❖ Requirement #11a – Project Due Dates by Requirements 1. During Each SPRINT, you are to submit the deliverable for that SPRINT. The table below shows which requirements YOU MUST SUBMIT during each SPRINT & the DUE DATES. 2. For each SPRINT, review the Requirement # due that SPRINT and the Date is due: SPRINT WEEK PHASES & Requirement # GRADE POINTS Start Date Due Date SPRINT #1 Week #1 PLANNING Requirement #1 Requirement #2 10 Points Wednesday 3/1 Wednesday 3/8 ANALYSIS Requirement #3 DESIGN Part 1 – Normalize Logical Model Only Requirement #4 Deliverable Requirement #11b SPRINT #2 Week #2 Week #3 DESIGN Part 2 – Dictionary & Physical Schema Diagram Only Requirement #5 Requirement #6 40 Points Wednesday 3/8 Monday 3/27 Deliverable Requirement #11c SPRINT #3 Week #4 DEVELOPMENT & IMPLEMENTATION (Development) Requirement #7 Requirement #8 25 Points Monday 3/27 Monday 4/3 Deliverable Requirement #11d SPRINT #4 Week #5 VALIDATION & TESTING (Testing) Requirement #9 20 Points Monday 4/3 Monday 4/10 OPERATION & MAINTENANCE Requirement #10 0 Points Deliverable Requirement #11e PROJECT SUBMISSION ( SUM of ALL SPRINTS! All Deliverables from ALL SPRINTS Submitted together ) 5 Points

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

242 Important: Submission process for SPRINT $4:  Important: You will need to submit partial deliverables during each sprint, but in the LAST SPRINT #4, everything is submitted as one large package!  This includes all updated files script & drawing files submitted again as part of the package.  BUT ONLY the FINAL UPDATED PROJECT DOCUMENT is submitted in the last SPRINT not the previous versions along with the package.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

243 ❖ Requirement #11b – Instructions for summitting SPRINT #1 ONLY 1. The project delivery schedule & timelines table in Requirement #11a provided a full picture of the deliverables, earned points, due dates etc., for ALL the Phases & Sprints. 2. The table below provides the steps on WHAT & HOW to submit SPRINT #1 ONLY . Sprint Requirements in scope of execution Deliverable Content & Steps How to Submit SPRINT #1 Requirement #1 Requirement #2 Requirement #3 Requirement #4 Steps to submit this SPRINT #1 : 1. SUBMIT the PDF Project Document with content from execution of ONLY Requirements #1, #2, #3 & #4 executed. 2. Project Document must be PDF document, NOT an MS Word etc. CONVERT WORD DOCUMENT TO PDF! 1. EMAIL Project Document PDF to arod1212@outlook.com ( DO NOT SEND or CC arod@microsoft.com ). 2. Email subject line should have the following syntax: ▪ For CST4708 CLASS: CST4708- YOUR FULL NAME- PROJECT1-SPRINT #1 . ▪ For CST3604 CLASS: CST3604- YOUR FULL NAME- PROJECT1-SPRINT #1 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

244 ❖ Requirement #11c – Instructions for summitting SPRINT #2 ONLY 1. The table below provides the steps on WHAT & HOW to submit SPRINT #2 ONLY . Sprint Requirements in scope of execution Deliverable Content & Steps How to Submit SPRINT #2 Requirement #5 Requirement #6 Steps to submit this SPRINT #2 : 1. HAVE READY the UPDATED PDF Project Document with the NEWLY ADDED content from execution of ONLY Requirements #5 & #6 executed. UPDATED Project Document must be PDF document, NOT an MS Word etc. CONVERT WORD DOCUMENT TO PDF! 2. HAVE READY the Physical Schema Diagram JPEG or other IMAGE FILE format FILE created from execution of Requirements #6 . The Physical Schema Diagram FILE MUST be submitted as a JPEG or other IMAGE FILE format . 3. CRFATE a FOLDER in your computer file system NAME the Folder Project1 SPRINT #2 . 4. ADD to the Folder Project1 SPRINT #2 the following content from this sprint: 1) the UPDATED PDF Project Document & 2) the Physical Schema Diagram created . 5. PACKAGE the entire FOLDER using WINZIP or Windows Compress Zip Program (in windows simply right- click folder|send to|compress ) to COMPRESS and CREATE a ZIP PACKAGE FILE . 6. DO NOT USE WINRAR!!!! WINZIP OR WINDOWS COMPRESS PROGRAM ONLY! 1. EMAIL the ZIP PACKAGE FILE to arod1212@outlook.com ( DO NOT SEND or CC arod@microsoft.com ). 2. Email subject line should have the following syntax: ▪ For CST4708 CLASS: CST4708- YOUR FULL NAME- PROJECT1-SPRINT #2 . ▪ For CST3604 CLASS: CST3604- YOUR FULL NAME- PROJECT1-SPRINT #2 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

245 ❖ Requirement #11d – Instructions for summitting SPRINT #3 ONLY 1. The table below provides the steps on WHAT & HOW to submit SPRINT #3 ONLY . Sprint Requirements in scope of execution Deliverable Content & Steps How to Submit SPRINT #3 Requirement #7 Requirement #8 Steps to submit this SPRINT #3 : 1. HAVE READY the UPDATED PDF Project Document with the NEWLY ADDED content from execution of ONLY Requirements #7 & #8 executed. UPDATED Project Document must be PDF document, NOT an MS Word etc. CONVERT WORD DOCUMENT TO PDF! 2. HAVE READY the actual Create Table Script ( CreateTable.sql ) FILE used to store & execute the CREATE TABLE Statements to implement your database during the execution of Requirements #7 . 3. HAVE READY the Physical Schema Diagram FILE GENERATED from Oracle 18c using Oracle SQL Developer during execution of Requirements #8 . The GENERATED Physical Schema Diagram FILE MUST be submitted as a JPEG or other IMAGE FILE format . Go to next step. 4. CRFATE a FOLDER in your computer file system NAME the Folder Project1 SPRINT #3 . 5. ADD to the Folder Project1 SPRINT #3 the following content from this sprint: 1) the UPDATED PDF Project Document , 2) the Create Table Script ( CreateTableScript.sql ) FILE, 3) the GENERATED Physical Schema Diagram FILE as a JPEG or other image Format . 1. EMAIL the ZIP PACKAGE FILE to arod1212@outlook.com ( DO NOT SEND or CC arod@microsoft.com ). 2. Email subject line should have the following syntax: ▪ For CST4708 CLASS: CST4708- YOUR FULL NAME- PROJECT1-SPRINT #3 . ▪ For CST3604 CLASS: CST3604- YOUR FULL NAME- PROJECT1-SPRINT #3 .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

246 6. ALSO ADD to the Folder Project1 SPRINT #3 the following content from PREVIOUS SPRINTS: 1) the Physical Schema Diagram FILE as a JPEG or other image Format, created in Requirement #6 of SPRINT #2 . The idea is that the FOLDER contains all Diagrams and Script Files from execution of the entire Project up to this SPRINT #3. 7. PACKAGE the entire FOLDER using WINZIP or Windows Compress Zip Program (in windows simply right- click folder|send to|compress ) to COMPRESS and CREATE a ZIP PACKAGE FILE 8. DO NOT USE WINRAR!!!! WINZIP OR WINDOWS COMPRESS PROGRAM ONLY!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

247 ❖ Requirement #11e – Instructions for summitting PROJECT 1 FINAL SPRINT #4 ONLY. THIS IS YOUR FINAL DELIVERABLE FOR ALL SPRINTS IN PROJECT 1 & WHAT WILL BE SUBMITTED TO THE CUSTOMER! 1. The table below provides the steps on WHAT & HOW to submit SPRINT #4 ONLY . Sprint Requirements in scope of execution Deliverable Content & Steps How to Submit SPRINT #4 (Final Sprint! All deliverables to be submitted!) Requirement #9 Requirement #10 Steps to submit this SPRINT #4 : 1. HAVE READY the FINAL UPDATED PDF Project Document with the NEWLY ADDED content from execution of ONLY Requirements #9 & #10 executed. UPDATED Project Document must be PDF document, NOT an MS Word etc. CONVERT WORD DOCUMENT TO PDF! 2. HAVE READY the actual Test Query Script ( TestSQLQueryScript.sql ) FILE used to store & execute the SELECT, INSERT, UPDATE & DELETE Statements to validate & test your database during the execution of Requirements #9 . 3. There is NO deliverable execution of Requirements #10 , nothing to submit. 4. CRFATE a FOLDER in your computer file system NAME the Folder Project1 Final SPRINT #4 . 5. ADD to the Folder Project1 Final SPRINT #4 the following content from this sprint: 1) the UPDATED PDF Project Document , 2) the Test Query Script ( TestSQLQueryScript.sql ) FILE used to store & execute the SELECT, INSERT, UPDATE & DELETE Statements to validate & test your database . 1. EMAIL the ZIP PACKAGE FILE to arod1212@outlook.com ( DO NOT SEND or CC arod@microsoft.com ). 2. Email subject line should have the following syntax: ▪ For CST4708 CLASS: CST4708- YOUR FULL NAME-PROJECT1-SPRINT #4-FINAL DELIVERABLE . ▪ For CST3604 CLASS: CST3604- YOUR FULL NAME-PROJECT1-SPRINT #4-FINAL DELIVERABLE .

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

248 6. ALSO ADD to the Folder Project1 SPRINT #4 the following content from PREVIOUS SPRINTS: 1) the Physical Schema Diagram FILE as a JPEG or other image Format, created in Requirement #6 of SPRINT #2 , 2) the Create Table Script ( CreateTableScript.sql ) FILE from Requirement #7 of SPRINT #3 , 3) the GENERATED Physical Schema Diagram FILE as a JPEG or other image Format, & 4) the Physical Schema Diagram FILE as a JPEG or other image Format, created in Requirement #8 of SPRINT #3 . The idea is that the FOLDER contains all Diagrams and Script Files from execution of the entire Project up to this SPRINT #4 . 7. INCLUDE IN THIS FOLDER THE FINAL DOCUMENT & ALL PROJECT FILES & DIAGRAM IN THE FINAL FOLDER! Summary of all files required for final submission: 1) File #1 - PDF version of the Final Project Design/Implementation Document with all requirements information, description, screen shots etc., (PDF ONLY!) 2) File #2 – Physical Schema Design Diagram Image File (JPEG, BITMAP, etc.) 3) File #3 - Create Table Script 4) File #4 – Generated Database Schema Table Diagram (JPEG or another Image format) 5) File #5 - Test SQL Queries Script 8. PACKAGE the entire FOLDER using WINZIP or Windows Compress Zip Program (in windows simply right- click folder|send to|compress ) to COMPRESS and CREATE a ZIP PACKAGE FILE . 9. DO NOT USE WINRAR!!!! WINZIP OR WINDOWS COMPRESS PROGRAM ONLY!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

249 Requirement #12 – Project Exam Expected Deliverables  FINAL DUE DATE (SPRINT #4 + ALL SPRINTS DELIVERABLES!): Tuesday APRIL 11 th , 2023  NO EXTENSIONS! NO EXCUSES!  WE WILL LOSE MONEY IF WE DO NOT MEET OUR DEADLINES!  THEREFORE, IS IMPORTANT WE DO NOT MISS ANY OF THE SPRINT DEADLINES SINCE OUR JOBS (GRADES) ARE AT RISKS!  DON’T WAIT TO START THIS PROJECT ON THE W EEKEND THAT IS DUE! START IMMEDIATELY! IT WILL REQUIRED A LOT OF WORK!!!  DON’T GET PARALYSIS! IF YOU ARE STUCK, DON’T UNDERSTAND WHAT TO DO, CONFUSED, AFRAID, GET HELP FROM PROFESSOR RODRIGUEZ ASAP!!

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

CST4708_CST3604-SPRING2023_PROJECT1_PART2_Detailed_Requirements(version6)

Related Documents