Systems analysis and design methods 7th whitten and benley chapter 11

Database Design Introduction  The chapter will address the following questions:      What are the similarities and differences between conventional files and modern, relational databases? What are of fields, records, files, and databases? What are some examples of each? What is a modern data architecture that includes files, operational databases, data warehouses, personal databases, and work group databases? What are the similarities and differences between the roles of systems analyst, data administrator, and database administrators as they relate to databases? What is the architecture of a database management system? Database Design Introduction  The chapter will address the following questions:     How does a relational database implement entities, attributes, and relationships from a logical data model? How you normalize a logical data model to remove impurities that can make a database unstable, inflexible, and non-scaleable? How you transform a logical data model into a physical, relational database schema? How you generate SQL code to create the database structures in a schema? Database Design Conventional Files Versus the Database  Introduction  All information systems create, read, update and delete data This data is stored in files and databases  Files are collections of similar records  Databases are collections of interrelated files • The key word is interrelated • The records in each file must allow for relationships (think of them as ‘pointers’) to the records in other files   In the file environment, data storage is built around the applications that will use the files In the database environment, applications will be built around the integrated database Database Design Information System File File Information System File Information System Database (consolidated & integrated data from files) File Information System Information System Database Design Conventional Files Versus the Database  The Pros and Cons of Conventional Files   Pros:  Conventional files are relatively easy to design and implement because they are normally based on a single application or information system  Historically, another advantage of conventional files has been processing speed Cons:  Duplication of data items in multiple files is normally cited as the principal disadvantage of file-based systems  A significant disadvantage of files is their inflexibility and nonscaleability Database Design Conventional Files Versus the Database  The Pros and Cons of Conventional Files  As legacy file-based systems and applications become candidates for reengineering, the trend is overwhelmingly in favor of replacing file-based systems and applications with database systems and applications Database Design Conventional Files Versus the Database  The Pros and Cons of Database  Pros:  The principal advantage of a database is the ability to share the same data across multiple applications and systems  Database technology offers the advantage of storing data in flexible formats  Databases allow the use of the data in ways not originally specified by the end-users - data independence  The database scope can even be extended without impacting existing programs that use it • New fields and record types can be added to the database without affecting current programs Database Design Conventional Files Versus the Database  The Pros and Cons of Database  Cons:  Database technology is more complex than file technology • Special software, called a database management system (DBMS), is required   A DBMS is still somewhat slower than file technology Database technology requires a significant investment • The cost of developing databases is higher because analysts and programmers must learn how to use the DBMS   In order to achieve the benefits of database technology, analysts and database specialists must adhere to rigorous design principles Another potential problem with the database approach is the increased vulnerability inherent in the use of shared data Database Design Conventional Files Versus the Database  Database Design in Perspective     To fully exploit the advantages of database technology, a database must be carefully designed The end product is called a database schema, a technical blueprint of the database Database design translates the data models that were developed for the system users during the definition phase, into data structures supported by the chosen database technology Subsequent to database design, system builders will construct those data structures using the language and tools of the chosen database technology Database Design INFORMATION SYSTEMS FRAMEWORK FOCUS ON SYSTEM DATA FOCUS ON SYSTEM PROCESSES FOCUS ON SYSTEM INTERFACES FOCUS ON SYSTEM GEOGRAPHY Business Subjects SYSTEM OWNERS (scope) Survey Phase (establish scope and project plan) Customers order zero, one, or more products Products may be ordered by zero, one, or more customers Study Phase (establish system improvement objectives) Data Requirements S Y S T E M A N A L Y S T S SYSTEM USERS (requirements) PRODUCT product-no product-name unit-of-measure unit-price quantity-available CUSTOMER cust omer-no cust omer-name cust omer-rating balance-due ORDER order-no order-date products-ordered quantities-ordered Definition Phase (establish and prioritize business system requirements) data models Database Schema SYSTEM DESIGNERS (specification) PRODUCT CUSTOMER product_no [Alpha(10)] INDEX customer_no [Alpha (10)] INDEXproduct_name [Alpha(32)] customer_name [Alpha(32)] unit_of_measure [Alpha(2)] customer_rating [Alpha(1)] INDEX unit_price [Real(3,2)] balance_due [Real(5,2)] quantity_available [Integer(4)] ORDER_PRODUCT ORDER order_no [Alpha(12)] INDEX ORDER.order_no order_date [Date(mmddyyyy) PRODUCT.product _no quantit y_ordered [Integer(2) CUSTOMER.customer_no Design Phase (translate business requirements into a technical design) Database Programs SYSTEM BUILDERS (components) FAST Methodology CREATE TABLE CUSTOMER (customer_no CHAR(10) NOT NULL customer_name CHAR(32) NOT NULL customer _rating CHAR(1) NOT NULL balance_due DECIMAL(5,2) CREATE INDEX cust_no_idx on CUSTOMER CREATE INDEX cust_rt_idx on CUSTOMER Existing Databases and Technology Existing Interfaces and Technology Existing Applications and Technology 10 Implementation Phase (translate technical design into code) Existing Networks and Technology Database Design Database Design  The Database Schema  The design of a database is depicted as a special model called a database schema  A database schema is the physical model or blueprint for a database It represents the technical implementation of the logical data model  A relational database schema defines the database structure in terms of tables, keys, indexes, and integrity rules  A database schema specifies details based on the capabilities, terminology, and constraints of the chosen database management system 55 Database Design Database Design  The Database Schema  Transforming the logical data model into a physical relational database schema rules and guidelines: Each fundamental, associative, and weak entity is implemented as a separate table • The primary key is identified as such and implemented as an index into the table • Each secondary key is implemented as its own index into the table • Each foreign key will be implemented as such • Attributes will be implemented with fields – These fields correspond to columns in the table 56 Database Design Database Design  The Database Schema  Transforming the logical data model into a physical relational database schema rules and guidelines: (continued) • The following technical details must usually be specified for each attribute – Data type Each DBMS supports different data types, and terms for those data types – Size of the Field Different DBMSs express precision of real numbers differently – NULL or NOT NULL Must the field have a value before the record can be committed to storage? – Domains Many DBMSs can automatically edit data to ensure that fields contain legal data – Default Many DBMSs allow a default value to be automatically set in the event that a user or programmer submits a record without a value 57 Database Design Database Design  The Database Schema  Transforming the logical data model into a physical relational database schema rules and guidelines: (continued) Supertype/subtype entities present additional options as follows: • Most CASE tools not currently support object-like constructs such as supertypes and subtypes • Most CASE tools default to creating a separate table for each entity supertype and subtype • If the subtypes are of similar size and data content, a database administrator may elect to collapse the subtypes into the supertype to create a single table Evaluate and specify referential integrity constraints 58 Database Design Database Design  Data and Referential Integrity   There are at least three types of data integrity that must be designed into any database - key integrity, domain integrity and referential integrity Key Integrity:  Every table should have a primary key (which may be concatenated) • The primary key must be controlled such that no two records in the table have the same primary key value • The primary key for a record must never be allowed to have a NULL value 59 Database Design Database Design  Data and Referential Integrity   Domain Integrity:  Appropriate controls must be designed to ensure that no field takes on a value that is outside of the range of legal values Referential Integrity:  A referential integrity error exists when a foreign key value in one table has no matching primary key value in the related table 60 Database Design Database Design  Data and Referential Integrity  Referential Integrity:  Referential integrity is specified in the form of deletion rules as follows: • No restriction – Any record in the table may be deleted without regard to any records in any other tables • Delete:Cascade – A deletion of a record in the table must be automatically followed by the deletion of matching records in a related table • Delete:Restrict – A deletion of a record in the table must be disallowed until any matching records are deleted from a related table 61 Database Design Database Design  Data and Referential Integrity  Referential Integrity:  Referential integrity is specified in the form of deletion rules as follows: (continued) • Delete:Set Null – A deletion of a record in the table must be automatically followed by setting any matching keys in a related table to the value NULL 62 Database Design Database Design  Roles    Some database shops insist that no two fields have exactly the same name  This presents an obvious problem with foreign keys A role name is an alternate name for a foreign key that clearly distinguishes the purpose that the foreign key serves in the table The decision to require role names or not is usually established by the data or database administrator 63 Database Design Database Design  Database Prototypes    Prototyping is not an alternative to carefully thought out database schemas On the other hand, once the schema is completed, a prototype database can usually be generated very quickly Most modern DBMSs include powerful, menu-driven database generators that automatically create a DDL and generate a prototype database from that DDL  A database can then be loaded with test data that will prove useful for prototyping and testing outputs, inputs, screens, and other systems components 64 Database Design Database Design  Database Capacity Planning   A database is stored on disk  The database administrator will want an estimate of disk capacity for the new database to ensure that sufficient disk space is available Database capacity planning can be calculated with simple arithmetic as follows For each table, sum the field sizes • This is the record size for the table For each table, multiply the record size times the number of entity instances to be included in the table • This is the table size 65 Database Design Database Design  Database Capacity Planning  Database capacity planning can be calculated with simple arithmetic as follows (continued) Sum the table sizes • This is the database size Optionally, add a slack capacity buffer (e.g., 10%) to account for unanticipated factors or inaccurate estimates above • This is the anticipated database capacity 66 Database Design Database Design  Database Structure Generation  CASE tools are frequently capable of generating SQL code for the database directly from a CASE-based database schema  This code can be exported to the DBMS for compilation  Even a small database model can require 50 pages or more of SQL data definition language code to create the tables, indexes, keys, fields, and triggers  Clearly, a CASE tool’s ability to automatically generate syntactically correct code is an enormous productivity advantage  Furthermore, it almost always proves easier to modify the database schema and re-generate the code, than to maintain the code directly 67 Database Design The Next Generation of Database Design  Introduction   Relational database technology is widely deployed and used in contemporary information system shops One new technology is slowly emerging that could ultimately change the landscape dramatically – object database management systems  The heir apparent to relational DBMSs, object database management systems store true objects, that is, encapsulated data and all of the processes that can act on that data  Because relational database management systems are so widely used, we don’t expect this change to happen quickly • It is expected that these vendors will either build object technology into their existing relational DBMSs, or they will create new, object DBMSs and provide for the transition between relational and object models 68 Database Design Summary        Introduction Conventional Files Versus the Database Database Concepts for the Systems Analyst Data Analysis for Database Design File Design Database Design The Next Generation of Database Design 69 ... file-based systems and applications become candidates for reengineering, the trend is overwhelmingly in favor of replacing file-based systems and applications with database systems and applications... Existing Databases and Technology Existing Interfaces and Technology Existing Applications and Technology 10 Implementation Phase (translate technical design into code) Existing Networks and Technology... retrieval and review without the overhead of regenerating the document 16 Database Design Database Concepts for the Systems Analyst  Files and Tables  Some of the types of files and tables