DATABASE ADMINISTRATION: Identify Physical Database Requirements
- 1. DATABASE ADMINISTRATION LEVEL III LEARNING GUIDE # 5 Learning Outcomes (LO) Page 1. Identify database scope -2- 1. Identify database requirements -24- 1. Identify security requirements -41- 1. Seek client feedback and approval -53- Unit of Competence : Identify Physical Database Requirements Module Title : Identifying Physical Database Requirements LG Code : ICT DBA3 M02 05 TTLM Code : ICT DBA3 TTLM 0817
- 2. • THE DATABASE ENVIRONMENT AND DEVELOPMENT PROCESS • After Studying This Information Sheet, You Should Be Able To: · Concisely Define Each of The Following Key Terms: Data, Database, Database Management System, Data Model, Information, Metadata, Enterprise Data Model, Entity, Relational Da- Abase, Enterprise Resource Planning (ERP) System, Database Application, Data Warehouse, Data Independence, Repository, User View, And Enterprise Data Modeling. • · Name Several Limitations of Conventional File Processing Systems. • · Explain At Least Ten Advantages of The Database Approach, Compared to Traditional File Pro- • Cussing. • · Identify Several Costs and Risks of The Database Approach. • · List and Briefly Describe Nine Components of a Typical Database Environment. • · Identify Four Categories of Applications That Use Databases and Their Key Characteristics LO1. Identify database scope
- 3. • BASIC CONCEPTS AND Definitions • A database as an organized collection of logically related data. • Data • the term data referred to facts concerning objects and events that could be recorded and stored on computer media. For example, in a salesperson’s database, the data would include facts such as customer name, address, and telephone number. • This type of data is called structured data. • The most important structured data types are numeric, character, and dates. Structured data are stored in tabular form (in tables, relations, arrays, spreadsheets, etc.) and are most commonly found in traditional databases and data warehouses. • An expanded definition of data that includes structured and unstructured types is “a stored representation of objects and events that have meaning and importance in the user’s environment.”
- 4. Data Versus Information • We define information as data that have been processed in such a way that the knowledge of the person who uses the data is increased. For example, consider the following list of facts: • Baker, Kenneth D. • Doyle, Joan E. • Finkle, Clive R. • Lewis, John C. • McFerrin, Debra R.
- 5. • Meta data • As we have indicated, data become useful only when placed in some context. The primary mechanism for providing context for data is metadata. Metadata are data that describe the properties or characteristics of end-user data and the context of that data. Some of the properties that are typically described include data names, definitions, length (or size), and allowable values • Traditional File Processing Systems • When computer-based data processing was first available, there were no databases. To be useful for business applications, computers had to store, manipulate, and retrieve large files of data. Computer file processing systems were developed for this purpose. These systems have been replaced by database processing systems in most business applications today.
- 6. Disadvantages of File Processing Systems •Program-Data Dependence • Duplication of Data • Limited Data Sharing • Lengthy Development Times • Excessive Program Maintenance FIGURE 1-2: OLD file PROCESSING SYSTEMS
- 7. The Database Approach • Data Models • Designing a database properly is fundamental to establishing a database that meets the needs of the users. Data models capture the nature of and relationships among data and are used at different levels of abstraction as a database is conceptualized and designed. The effectiveness and efficiency of a database is directly associated with the structure of the database. • data model is made up entities, attributes, and relationships and the most common data modeling representation is the entity-relationship model. A brief description is presented below.
- 8. E-R notation Basic symbols : Entity Relationship Primary key Attribute Multivalued attribute Gerund Relationship degree : Unary Binary Ternary Optional zero-many cardinality (0,1,2, ..., many) Mandatory 1 cardinality Many(M) cardinality (1,2,.. ,many) Optional 0 or 1 cardinality Relationship cardinality: ISA Class-subclass relationship Exclusive relationship
- 9. Entities • Is an object in the real world that is distinguishable from other objects • Relationships • A well-structured database establishes the relationships between entities that exist in organizational data so that desired information can be retrieved. Most relationships are one-to-many (1:M) or many-to-many (M: N). A customer can place (the Places relationship) more than one order with a company. • Relational Databases • Relational databases establish the relationships between entities by means of common fields included in a file, called a relation. STUDENT COURSE Completes Many to many
- 10. Database Management Systems • A database management system (DBMS) is a software system that enables the use of a database approach. The primary purpose of a DBMS is to provide a systematic method of creating, updating, storing, and retrieving the data stored in a database. It enables end users and application programmers to share data, and it enables data to be shared among multiple applications rather than propagated and stored in new files for every new application. A DBMS also provides facilities for controlling data access, enforcing data integrity, managing concurrency control, and restoring a database.
- 11. ADVANTAGES OF THE DATABASE APPROACH • Program-Data Independence • Planned Data Redundancy • Improved Data Consistency • Improved Data Sharing • Increased Productivity of Application Development • Enforcement of Standards • Improved Data Quality • Improved Data Accessibility and Responsiveness • Reduced Program Maintenance • Improved Decision Support
- 12. COSTS AND RISKS OF THE DATABASE APPROACH • New, Specialized Personnel • Installation and Management Cost and Complexity • Conversion Costs • Need for Explicit Backup and Recovery • ORGANIZATIONAL Conflict
- 13. Components of the Database Environment • Now that you have seen the advantages and risks of using the database approach to managing data, let us examine the major components of a typical database environment and their relationships. Following is a brief description of the nine components shown in Figure 1-5: • Computer-aided software engineering (CASE) tools. CASE tools • Repository • DBMS. • Database. • Application programs • User interface • Data and database administrators • System developers • End users • hardware, software, and people
- 14. The Range of Database Applications • Personal Databases • Personal databases are designed to support one user. Personal databases have long resided on personal computers (PCs), including laptops, and increasingly on smart phones and PDAs. • TWO-TIER CLIENT/SERVER DATABASES • Often, what starts off as a single-user database evolves into something that needs to be shared among several users. A workgroup is a relatively small team of people (typically fewer than 25 persons) who collaborate on the same project or application or on a group of similar projects or applications. These persons might be engaged (for example) with a construction project or with developing a new computer application and need to share data amongst the group.
- 16. • MULTITIER CLIENT/SERVER DATABASES • One of the drawbacks of the two-tier database architecture is that the amount of functionality that needs to be programmed into the application on the users’ computer can be pretty significant because it needs to contain both the user interface logic as well as the business logic. This, of course, means that the client computers need to be powerful enough to handle the programmed application.
- 17. • ENTERPRISE APPLICATIONS • An enterprise application/database is one whose scope is the entire organization or enterprise (or, at least, many different departments). Such databases are intended to support organization-wide operations and decision making. Note that an organization may have several enterprise databases, so such a database is not inclusive of all organizational data. The evolution of enterprise databases has resulted in two major developments: • Enterprise resource planning (ERP) systems • 2. Data warehousing implementations
- 18. Match the following terms and definitions • __________ 1. data • __________ 2. database application • __________ 3. constraint • __________ 4. repository • __________ 5. metadata • __________ 6. data warehouse • __________ 7. Information F. includes data definitions and constraints • __________ 8. user view • __________ 9. database management • __________ 10. data independence • __________ 11. Database • __________ 12. enterprise resource plan-Ning (ERP) • __________ 13. systems development life cycle (SDLC) • __________ 14. prototyping • __________ 15. enterprise data model K. a software application that is used to create, maintain, and • __________ 16. conceptual schema consists of two data models: a logical model and a physical • __________ 17. internal schema • __________ 18. external schema model A. data placed in context or summarized B. application program(s) C. facts, text, graphics, images, etc. D. a graphical model that shows the high-level entities for the organization and the relationships among those entities E. organized collection of related data F. centralized storehouse for all data definitions G. separation of data description from programs system H. A business management system that integrates all functions of the enterprise logical description of portion of database I. provide controlled access to user databases J. a rule that cannot be violated by database users K. integrated decision support database L. consist of the enterprise data model and multiple user views M. a rapid approach to systems development N. a comprehensive description of business data O. a structured, step-by-step approach to systems development
- 19. DATABASE DESIGN PLANNING • What Is Database Design? • · Importance of Database Design · Planning Database Design · Trademarks of A Solid Database Design · Design Methodologies · Logical Versus Physical Modeling • What Is a Database Design? • Webster’s dictionary uses the following phrases to define the term design: • · “To prepare the preliminary plans or sketch for” • · “To intend for a definite purpose” • · “The combination of details or features of something constructed” • · “To plan and fashion artistically or skillfully” • · “Adaptation of means to a preconceived end”
- 20. • “Many “details and features” are involved during the design of any database. Three very basic phases of database design exist: 1. Requirements gathering—Is the process of conducting meetings and/or interviews with customers, end users, and other individuals in the company to establish the requirements for the proposed database. Requirements involve, but are not limited to, the following information: •How the business does business •Business rules and processes
- 21. 2. Data modeling—Is the process of visually representing the data for a business, and then eventually converting the business model into a data model. The data model generated is used to ultimately create the tables, views, and other objects that comprise the database. 3 Database design and normalization—Is a phase in which the business model (logical model) is converted into a physical model (tables). Also, part of design is normalization, or the reduction or elimination of data redundancy.
- 22. •Importance of Database Design •The main reason good database design is so important is that organization is promoted. The designers have more control over the design, implementation, and management of any project if the project is well thought out. Because the database design’s goal is to completely capture all a business’ data storage needs, its product should be an accurate and easy-to-use database that performs well. •Planning Database Design • The only true chance the design team has to get a handle on the design of a database takes place before the design process actually begins. Before any significant action should be taken toward gathering requirements, business modeling, or database design, a solid plan must be devised.
- 23. •The Mission Statement • The mission statement is a summation of the overall purpose of the proposed database. Typically, management is the main force involved in determining the mission statement. Management, developers, and end users are all involved in determining the mission objectives, or the detailed goals set forth for the database. • The mission statement should be further refined by answering the following questions: • What is the purpose of the database? • Who will use the database? • What type of database will this be? • What models and methodologies will be used? • Is this a new database? • Will this database be molded after a legacy database? • Will the database need to be modified in the near future? • Will there be multiple databases? • How will the customer access the database?
- 24. Mission Statement and Objectives for Our Model Company, TriTech •Mission statement—An automated business system is needed to manage and track student class registrations, class schedules, instructors, and instructor availability. •Mission objectives: The manual process of managing the training program will be automated. Internal users will be accessing the database. The relational model will be used. An automated design (AD) tool will be used to design the database. Currently no database is in place to meet the present needs (no legacy database). The database might need to be modified as the training company grows and more data storage requirements are established.
- 25. •DEVISING A WORK PLAN •After the mission statement and design objectives have been defined, it is time to devise a work plan that will be used as a guide for the design of the database. A work plan is an outline that breaks down the steps involved. •Following are preliminary considerations for planning a work plan: Location of the work to be conducted. A design team must be established. Business rules. Hardware to be used. Software to be used. Tools for development. Tools for the end users. Backup plan for development work done. Database environments used for development. Basic standards and naming conventions. Database environment for production.
- 26. •SETTING MILESTONES AND MAKING DEADLINES A milestone is a significant point in the database design process. • Following are common milestones: • All business requirements are gathered. • A work plan is devised. • Entities and attributes are established. • The logical design of the database is complete. • The physical design of the database is complete. • The database is tested. • The database is implemented into production. • Project time frames should be determined for each milestone established. Deadline dates are established and associated with each milestone.
- 27. Establishing the Design Team and Assigning Tasks • After a work plan has been established and milestones with deadlines are set, a design (development) team is established if one does not already exist. The design team might consist of one or many individuals. The responsibility to design a database might fall into the hands of only one individual for smaller companies.
- 28. Trademarks of a Solid Database Design Trademarks of a good database design include •A functional database is generated. •The database accurately represents the business’s data. •The database will be easy to use and maintain. •Acceptable response time exists for the end users. •Modifications are easily made to the structure. •Data can be retrieved and modified easily. •Down time because of poor design is minimized. •Very little maintenance is needed. •Data is kept safe by planning for security. •Redundant data is minimized or nonexistent. Data can be easily backed up or recovered. •The actual structure of the database will be virtually transparent to the end user.
- 29. •Overview of Design Methodologies •A methodology represents the thought process used by the design team in order to develop a database model. Some of the questions that should be raised when selecting a design methodology are • What tools are available to aid in design? • How critical is development time? • What are the skills of the developers? • Will the project require outsourcing? • What resources are available for the project?
- 30. •Design methodology traditionally involves the following three phases: • 1. Requirements analysis • 2. Data modeling • 3. Design and Normalization •Two types of data modeling are as follows: Logical modeling Physical modeling •Logical Modeling • Logical modeling deals with gathering business requirements and converting those requirements into a model. • The logical model revolves around the needs of the business, not the database, although the needs of the business are used to establish the needs of the database.
- 31. •Typical deliverables of logical modeling include Entity relationship diagrams Business process diagrams User feedback documentation • Typical design phases that apply to logical modeling: Gathering requirements Requirements analysis • Physical Modeling • Physical modeling involves the actual design of a database according to the requirements that were established during logical modeling. Typical deliverables of physical modeling include the following: • Server model diagrams • User feedback documentation • Database design documentation • Typical development phases that apply to physical modeling: • Design • Implementation • Maintenance
- 32. LO2: IDENTIFY DATABASE REQUIREMENTS •Understanding user needs • designing any custom product, whether it’s a database, beach house, or case mod, is largely a translation process. you need to translate the customers’ needs, wants, and desires from the sometimes-fuzzy ideas floating around in their heads into a product that meets the customers’ needs. the first step in the translation process is understanding the user’s requirements
- 33. PHYSICAL DATABASE DESIGN AND PERFORMANCE •The Physical Database Design Process • The primary goal of physical database design is data processing efficiency. • Designing physical files and databases requires certain information that should have been collected and produced during prior systems development phases. The information needed for physical file and database design includes these requirements: • Designing physical files and databases requires certain information that should have been collected and produced during prior systems development phases.
- 34. Data Volume and Usage Analysis •data volume and frequency-of-use statistics are important inputs to the physical database design process, particularly in the case of very large-scale database implementations. Thus, you have to maintain a good understanding of the size and usage patterns of the database throughout its life cycle. In this section, we discuss data volume and usage analysis as if it were a one-time static activity, but in practice, you should continuously monitor significant changes in usage and data volumes.
- 36. Designing Fields • A field is the smallest unit of application data recognized by system software, such as a programming language or database management system. • A field corresponds to a simple attribute in the logical data model, and so in the case of a composite attribute, a field represents a single component. •CHOOSING DATA TYPES • A data type is a detailed coding scheme recognized by system software, such as a DBMS, for representing organizational data. • Selecting a data type involves four objectives that will have different relative levels of importance for different applications: • 1. Represent all possible values. • 2. Improve data integrity. • 3. Support all data manipulations. • 4. Minimize storage space.
- 37. CONTROLLING DATA INTEGRITY • DBMSs, data integrity controls (i.e., controls on the possible value a field can assume) can be built into the physical structure of the fields and controls enforced by the DBMS on those fields.
- 38. • Default value. A default value is the value a field will assume unless a user enters an explicit value for an instance of that field. • Range control. A range control limits the set of permissible values a field may assume. • Null value control. A null value is defined as an empty value. • Referential integrity. Referential integrity on a field is a form of range control in which the value of that field must exist as the value in some field in another row of the same or • (most commonly) a different table. •Handling Missing Data • When a field may be null, simply entering no value may be sufficient. For example, suppose a customer zip code field is null and a report summarizes total sales by month and zip code.
- 39. End of LO2
- 40. LO3: IDENTIFY SECURITY REQUIREMENTS Managing Data Security • The goal of database security is to protect data from accidental or intentional threats to their integrity and access. • The database environment has grown more complex, with distributed databases located on client/server architectures and personal computers as well as on mainframes. • For example, computer listings or computer disks containing sensitive data should not be left unattended on desktops. • Data administration is often responsible for developing overall policies and procedures to protect databases. • Database administration is typically responsible for administering database security on a daily basis.
- 41. HOW IS SECURITY IMPORTANT TO DATABASE DESIGN? • For users to access the system, it must be accessible on the local (LAN) or wide area network (WAN) and these day’s most often via the World Wide Web as well. Applications using Web browsers as the primary user interface are so common as to be the norm for new development. When we put the database on the Web, it becomes vulnerable to hackers and other criminals from outside your organization who will damage your system or steal your data just because they can. Imagine that everyone’s salary, personnel files, or your company’s trade secrets are posted for public view on a Web site.
- 42. Threats to Data Security • Threats to data security may be direct threats to the database. For example, those who gain unauthorized access to a database may then browse, change, or even steal the data to which they have gained access. • All parts of the system must be secure, including the database, the network, the operating system, the building(s) in which the database resides physically, and the personnel who have any opportunity to access the system. • The following threats must be addressed in a comprehensive data security plan: •Accidental losses, including human error, software, and hardware-caused breaches. •Theft and fraud •Loss of privacy or confidentiality •Loss of data integrity •Loss of availability.
- 43. Who Needs Access to The Database? • Most information required throughout design and for implementation will be gathered from interviews during analysis. In order to plan for database security during database design and enforce the security after implementation, all users of the database must first be established. There are potentially different categories of users for any information system, ranging from end users to administrators of the information system. • the most common users, or individuals who might have access to any information system, include End users Customers Management Network administrator System administrator Database administrator Schema owner