Presentation is loading. Please wait.

Presentation is loading. Please wait.

PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design.

Similar presentations

Presentation on theme: "PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design."— Presentation transcript:

1 PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design

2 Chapter Objectives Explain data design concepts and data structures
Describe file processing systems and various types of files Understand database systems and define the components of a database management system (DBMS) Describe Web-based data design 3

3 Chapter Objectives Explain data design terminology, including entities, fields, common fields, records, files, tables, and key fields Describe data relationships, draw an entity-relationship diagram, define cardinality, and use cardinality notation Explain the concept of normalization Explain the importance of codes and describe various coding schemes 3

4 Chapter Objectives Describe relational and object-oriented database models Explain data warehousing and data mining Differentiate between logical and physical storage and records Explain data control measures

5 Introduction You will develop a physical plan for data organization, storage, and retrieval Begins with a review of data design concepts and terminology, then discusses file-based systems and database systems, including Web-based databases Concludes with a discussion of data storage and access, including strategic tools such as data warehousing and data mining, physical design issues, logical and physical records, data storage formats, and data control 4

6 Data Design Concepts Data Structures
A file or table contains data about people, places, things, or events that interact with the system File-oriented system File processing system Database system Data Structure A framework for organizing and storing data in an information system. Consists of files or tables linked in various ways. Depending on this link  either a file processing system or  database management system

7 Data Design Concepts Overview of File Processing Potential problems
Data redundancy Data integrity Rigid data structure File Processing A system that uses files that contain all the data necessary for inquiries/reporting It is still used. It is efficient, because … They do not require the additional processor time and memory space needed by preprogrammed database functions They are simple to create, especially when a data file is accessed by only one application They can be tailored tightly to specific application or business needs Disadvantages: Data redundancy results because each department has its own files, and the same data (such as an employee name) frequently appears in each of those files In a file processing system, the need to make changes to data in multiple files (which results from data redundancy) can compromise data integrity. The rigid data structure of a file processing system results from a department’s data files usually being closely tied to the department’s applications. This can make it difficult for managers who require information from multiple departments Example: previous slide  3 items of information (mechanic no, name, and payrate) are stored in both data files

8 Data Design Concepts Overview of File Processing
Uses various types of files Master file Table file Transaction file Work file – scratch file Security file History file These files are used by a file processing system. Master File: Dynamic file that stores permanent type data and contains one record for each record Ex. School maintains master files for courses, students, faculty Table File: Contains reference data used by the information system Static and not updated by information system Ex. Tax tables, Postage rate tables, Zip code tables Transaction File: Stores records that contain day-to-day business and operational data An input file that updates a master file Ex. Charges, Payments Work File or Scratch File: A temporary file created by in information system for a single task. Usually created by one process in the information system and used by another process within the same system. Ex. Sorted files, Report files, Output reports until printed Security File: Created and saved for backup and recovery purposes Ex. Audit trail files, backups of master, table transaction files History File: Created for archiving purposes Ex. Inactive Student file  If student hasn’t register in last 2 semesters, student deleted from active student master and added to inactive. If re-registers, deleted from inactive and added back to active student master

9 Data Design Concepts Overview of Database Systems
A properly designed database system offers a solution to the problems of file processing Provides an overall framework that avoids data redundancy and supports a real-time, dynamic environment Database management system (DBMS) The main advantage of a DBMS is that it offers timely, interactive, and flexible data access

10 Data Design Concepts Overview of Database Systems Advantages
Scalability Better support for client/server systems Economy of scale Flexible data sharing Enterprise-wide application – database administrator (DBA) Stronger standards Scalability  system can be expanded, modified, or downsized to meet changing needs of business Client/Server support  these systems require power and flexibility of a db design Economies of Scale  a company that uses an enterprise-wide db with a powerful mainframe server instead of several smaller computers is saving money through economies of scale. The more processing, the cheaper it gets. Flexible Data Sharing  The usage of a DB allows users to access information from anywhere and view consistent information in different ways DBA  The Database Administrator typically administers the databse. Stronger Standards  Important to have standardization on data names, formats, and documentation throughout the organization used in the database (DBA helps to ensure)

11 Data Design Concepts Overview of Database Systems Advantages
Controlled redundancy Better security Increased programmer productivity Data independence Advantages of DB Systems Controlled Redundancy: We are not storing data in numerous place Reduces inconsistency and data errors Data items do not need to be duplicated in multiple locations Better Security: DBA defines authorization procedures to ensure correct access to db Programmer Productivity: Programmers to not have to create the underlying file structure for a database They can concentrate on logical design and a new db application can be developed more quickly than a file-oriented system Data Independence: Systems that interact with a DBMS are relatively independent of how the physical data is maintained Thus you can alter data structures without modifying the systems that use data

12 Data Design Concepts Database Tradeoffs
Because DBMSs are powerful, they require more expensive hardware, software, and data networks capable of supporting a multi-user environment More complex than a file processing system Procedures for security, backup, and recovery are more complicated and critical

13 DBMS Components Interfaces for Users, Database Administrators, and Related Systems Users Query language Query by example (QBE) SQL (structured query language) Database Administrators A DBA is responsible for DBMS management and support To work with the data within a DBMS there are several options: Query Language: A query is a request for specific data from a database. Query languages allow users to specify the data to display, print, or store. Each query language has its own grammar and vocabulary. Even without a programming background, most query languages can be learned in a short time. Query By Example: Query by example provides a graphical user interface to assist users with retrieving data. QBE is a relatively simple concept in which users are led intuitively through a query, step by step. Most DBMSs provide a QBE feature. (Access) SQL (Structured Query Language): SQL truly is a multiplatform tool. SQL is available in popular database programs for personal computers and networks, and most relational databases for midrange servers and mainframes include SQL. At one time, only professional programmers could access mainframe data. Database Administrators: The DBA maintains the database and assesses its requirements. Many large companies have both a DBA and a database analyst (DA), or data modeler, who focuses on the meaning and use of data. In smaller companies, one person often assumes both roles.

14 DBMS Components Interfaces for Users, Database Administrators, and Related Systems Related information systems A DBMS can support several related information systems that provide input to, and require specific data from, the DBMS Related information systems: With these systems, unlike a human interface, no human intervention is required for the 2-way communication that occurs between the DBMS and the related systems.

15 DBMS Components Data Manipulation Language Schema
A data manipulation language (DML) controls database operations, including storing, retrieving, updating, and deleting data Schema The complete definition of a database, including descriptions of all fields, tables, and relationships, is called a schema You also can define one or more subschemas Data Manipulation Language: DML serves the user who is querying a database. Some DBMSs, such as Microsoft Access, use QBE to hide the DML from a user Schema: Describes the structure of the database and contains descriptive information about the stored data, including access and content controls, relationships among data elements, and details of physical data store organization. Subschema: A view of the database that a particular system or user needs or is allowed to access To protect privacy project management system does not retrieve employee pay rates This could be used to restrict the level of access the a user is given to the schema some users can only update data, others can delete and create

16 DBMS Components Physical Data Repository
The data dictionary is transformed into a physical data repository, which also contains the schema and subschemas The physical repository might be centralized, or distributed at several locations ODBC – open database connectivity JDBC – Java database connectivity ODBC Uses SQL statements that the DBMS understands and can execute JDBC Enables Java applications to exchange data with any database that uses SQL statements and is JDBC-compliant

17 Web-Based Database Design
Characteristics of Web-Based Design In a Web-based design, the Internet serves as the front end, or interface, for the database management system Internet technology provides enormous power and flexibility Web-based systems are popular because they offer ease of access, cost-effectiveness, and worldwide connectivity

18 Web-Based Database Design
Connecting a Database to the Web Database must be connected to the Internet or intranet Middleware Macromedia’s ColdFusion To access data in a Web-based system, the db must be connected to the Internet or intrnet The db and the Internet speak two different languages, however Db have nothing to do with HTML, the language of the Web Middleware: Software that allows DB to connect to the Web and enable data to be viewed and updated ColdFusion – A Middleware product to accelerate the deploy web applications

19 Web-Based Database Design
Data Security Web-based data must be totally secure, yet easily accessible to authorized users To achieve this goal, well-designed systems provide security at three levels: The database itself The Web server The telecommunication links that connect the components of the system

20 Data Design Terminology
Definitions Entity Table or file Field Attribute Common field Record Tuple Now it is time for the systems analyst to select a design approach and begin to construct the system. Entity: Something we are collecting and maintaining data about  a person, place, thing, or event Table/File: Data is organized into tables or files which contain related records about the entity Structure consists of columns and rows Field: Attribute or characteristic about the entity. First Name, Last Name, Address A common field is an attribute that appears in more than one entity can is used to link entities in various types of relationships (primary  foreign keys) Record: Also called tuple  describes one instance or occurrence of an entity A set of related fields

21 Data Design Terminology
Key Fields Primary key Composite key (aka Combination key , Concatenated key, Multi-valued key) Candidate key Nonkey field Foreign key Secondary key Primary Key Uniquely identifies a field or combination of fields of an entity Would you want to use a field like Name for a Key field? No Why not? Not Unique Composite Key A combination of 2 or more key fields that make up the primary key Candidate Key Before you choose the primary key, a candidate key is a field that could be a choice for the primary key If not chosen, this is a nonkey Foreign Key A field in one table that matches a primary key in another table to establish the relationship between the two tables The foreign key does not have to be unique Ex. Carlton Smith has Advisor 49. The value 49 must be a unique value in the ADVISOR table because it is the PK but 49 can appear any number of times in the STUDENT table, where the advisor number is a foreign key. Turn to pg. 317  Figure Bottom: Student-Number and Course-ID are foreign keys that serve as the PK in the GRADE table. Using both of these fields as the PK assures the the grade will be assigned to the proper student in the proper courses Secondary Keys Key values that are not unique Zip Code

22 Data Design Terminology
Referential Integrity Validity checks can help avoid data input errors A type of validity check that is a set of rules that will not allow … data inconsistencies quality problems When refer to a relational db, it means that … A foreign key value cannot be entered in one table unless you have the matching primary key in another table. You cannot enter a customer order into the ORDER table unless that customer already exists in the CUSTOMER table If you don’t have referential integrity you could end up with an orphan order because there was not related customer If you had an Order Master and an Order Detail table and you don’t have referential integrity you could end up deleting the order master records from the ORDER MASTER table leaving the ORDER DETAIL records as orphans.

23 Entity-Relationship Diagrams
An entity is a person, place, thing, or event for which data is collected and maintained Provides an overall view of the system, and a blueprint for creating the physical data structures Entity-relationship diagram ERD a model that shows the logical relationships and interaction among system entities. Provides an overall view of the system and blueprint for creating physical data structures

24 Entity-Relationship Diagrams
Drawing an ERD The first step is to list the entities that you identified during the fact-finding process and to consider the nature of the relationships that link them Entities are labeled with singular nouns Relationships are diamond shapes ERDs depict relationships, not data or information flows

25 Entity-Relationship Diagrams
Types of Relationships One-to-one relationship (1:1) One-to-many relationship (1:M) Many-to-many relationship (M:N) Associative entity There are 3 types of Relationships that can exist between entities: 1-1 exists when exactly one of the 2nd entity occurs for each instance of the 1st entity Figure 7-15, pg. 318 1-M exists when one occurrence of the 1st entity can relate to many instances of the 2nd entity, but each instance of the 2nd entity can associate with only one instance of the 1st entity Figure 7-16, pg. 319 M-M exists when one instance of the 1st entity can relate to many instances of the 2nd entity , and one instance of the 2nd entity can relate to many instances of the 1st entity Figure 7-17, pg. 319 Notice the M-M is different from the 1:1 or 1:M in in that the event or transaction that links the 2 entities together is actually a third entity, called an associative entity that has its own characteristics.

26 Entity-Relationship Diagrams
Cardinality Cardinality notation Crow’s foot notation Cardinality: After drawing the initial ERD then you need to determine how many instances of one entity relate to instances of the other entity. This technique is called cardinality. Cardinality Notation: Modeling this interaction is done by using special symbols that represent the relationship, termed cardinality notation. Crow’s Foot Notation: The symbols used for the notation include circles, bars, and symbols that resemble crow’s feet. Figure 7-20, Pg. 321  Notation Single Bar  |  indicates one Double Bar  | |  indicates one and only one Circle  indicates zero Crow’s Foot  indicates many Go through Figure 7-20, pg. 321

27 Normalization Table design
Involves four stages: unnormalized design, first normal form, second normal form, and third normal form Most business-related databases must be designed in third normal form We now start the process of creating our tables but this is only a logical view. These tables may or may not translate into actual tables in the physical design. Normalization: Is a process where we create table designs by assigning specific fields to each table in the database based on a set of rules with the goal in mind to correct inherent problems with our table design. It involves 4 stages: Unnormalized Design, 1NF, 2NF, 3NF The 3 normal forms constitute a progression in 3NF is the best design Must business db must be designed in 3NF

28 Normalization Standard Notation Format
Designing tables is easier if you use a standard notation format to show a table’s structure, fields, and primary key Example: NAME (FIELD 1, FIELD 2, FIELD 3)

29 Normalization Repeating Groups and Unnormalized Designs
Often occur in manual documents prepared by users Unnormalized design The first inherent problem with unnormalized data is something called repeating groups. A group of fields that occur any number of times in a single record with each occurrence have different values. They often occur in manual documents. Ex. A report card with student’s information at the top followed by a list of courses and grades at the bottom. This academic or grade information would represent a repeating group. P. 7-22, pg. 323 Think of repeating group as set of child (subsidiary) records contained within the parent (main) record.

30 Normalization First Normal Form Second Normal Form
A table is in first normal form (1NF) if it does not contain a repeating group To convert, you must expand the table’s primary key to include the primary key of the repeating group Second Normal Form To understand second normal form (2NF), you must understand the concept of functional dependence Functionally dependent 1NF: A table is in 1NF if it DOES NOT contain a repeating group You give the new table the new primary key and include that as a FK in the original table Pg. 323, Figure 722 Raw, Pg. 324, Figure 723 – 1NF 2NF: The table is in 1NF AND all fields that are not part of the primary key are functionally dependent on the entire primary key.

31 Normalization Second Normal Form
A standard process exists for converting a table from 1NF to 2NF Create and name a separate table for each field in the existing primary key Create a new table for each possible combination of the original primary key fields Study the three tables and place each field with its appropriate primary key

32 Normalization Second Normal Form
Four kinds of problems are found with 1NF designs that do not exist in 2NF Consider the work necessary to change a particular product’s description 1NF tables can contain inconsistent data Adding a new product is a problem Deleting a product is a problem 2NF: Consider Work to Make Changes to Fields: If there are 500 current orders for Product #304  We have to modify 500 records. Updating would be cumbersome and expensive. 1NF Table Contain Inconsistent Data: Entering data manually leaves you wide open to mismatching of data. Adding A New Product is a Problem: Because PK includes Order Number and Product #, you need values for both fields to add a record. How do you enter a new product that has not yet ben ordered by a customer? Could use a dummy order number but can create difficulties. Pg. 326, Figure 7-24

33 Normalization Third Normal Form
3NF design avoids redundancy and data integrity problems that still can exist in 2NF designs A table design is in third normal form (3NF) if it is in 2NF and if no nonkey field is dependent on another nonkey field To convert the table to 3NF, you must remove all fields from the 2NF table that depend on another nonkey field and place them in a new table that uses the nonkey field as a primary key Figure 7-26, pg NF Figure 7-27, pg 328 3NF

34 Normalization A Normalization Example
To show the normalization process, consider the familiar situation, which depicts several entities in a school advising system: ADVISOR, COURSE, and STUDENT

35 Steps in Database Design
Create the initial ERD Assign all data elements to entities Create 3NF designs for all tables, taking care to identify all primary, secondary, and foreign keys Verify all data dictionary entries After creating your final ERD and normalized table designs, you can transform them into a database Create ERD: Review the DFDs to identify system entities, talk to users Create a draft ERD Analyze each relationship of the ERD to see if it is 1:1, 1:m, or M:N Figure 7-39, p. 337 Assign all data elements to entities: Verify that every data element in DD is associated logically with an entity Create 3NF designs for all tables, taking care to identify all primary, secondary, and foreign keys Generate the final ERD that will include new entities identified during normalization Figure 7-40, p. 338 Verify all data dictionary entries Verify and check all entries have been made for data stores, records, and data elements, and codes. Transformation into a database will take place once finished and other steps have been completed.

36 Chapter Summary Any questions?
Files and tables contain data about people, places, things, or events that affect the information system DBMS designs are more powerful and flexible than traditional file-oriented systems Data design tasks include creating an initial ERD; assigning data elements to an entity; normalizing all table designs; and completing the data dictionary entries for files, records, and data elements Any questions? 49

Download ppt "PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design."

Similar presentations

Ads by Google