Chapter 10 Designing the Files and Databases

SAD/CHAPTER 102 Learning Objectives Discuss the conversion from a logical data model to a physical database schema Understand the issues related to the physical design of fields, records, and files Identify the common file types and their applications

SAD/CHAPTER 103 Learning Objectives Understand the concepts of data integrity and referential integrity, and the various methods available as controls Identify the basic characteristics of the four common database architectures

SAD/CHAPTER 104 File and Database Design Goals The accurate translation of the logical relations into a technical specification Specifying the storage requirements and technologies for all data to be contained in the system

SAD/CHAPTER 105 Designing and Specifying Fields Data Attribute The smallest unit specified in the logical model Field The smallest unit specified in the physical model

SAD/CHAPTER 106 Field Types Primary Key Foreign Key Non-key

SAD/CHAPTER 107 Figure Common Field Types Primary Key Descriptive Fields Foreign Key

SAD/CHAPTER 108 Data Types A detailed specification of the fields Primitive Data Type User-Defined Data Type

SAD/CHAPTER 109 Table Common Data Type Definitions

SAD/CHAPTER 1010 Field Representation The process of determining how each field must be recorded in the data dictionary Examples: Ownership of the data element Coding method for data values Procedures for handling missing data values

SAD/CHAPTER 1011 Table Common Field-Level Data Specifications

SAD/CHAPTER 1012 Calculated Field Values Compute-on-demand The calculated field is represented in the data dictionary but not stored in the file Recalculate-on-demand The field actually contains a value, but it is not recomputed unless there is a change in the values used to calculate it

SAD/CHAPTER 1013 Data Integrity Key Integrity Domain Integrity Referential Integrity

SAD/CHAPTER 1014 Key Integrity Ensure every file has a unique primary key Prevent any two records from having the same primary key value Primary key field must never be allowed to have a null value

SAD/CHAPTER 1015 Domain Integrity Ensure no data element value in a file or database is outside its range Any control imposed on a field will always be imposed on data entered or stored in that field, no matter what the circumstances

SAD/CHAPTER 1016 Table Common Domain Controls

SAD/CHAPTER 1017 Figure Example of Referential Integrity Between Files CUSTOMER (Customer ID, LastName, FirstName, Address, City, State, Zipcode) ORDER (Order ID, Customer ID, OrderDate)

SAD/CHAPTER 1018 Referential Integrity Exists when the foreign key value in one file has no matching primary key value in another related file Deletion rules (Table 10-4)

SAD/CHAPTER 1019 Table Example of Referential Integrity Deletion Rules

SAD/CHAPTER 1020 Figure Examples of Proper and Improper Field Sequencing IMPROPER PROPER

SAD/CHAPTER 1021 Record Length Fixed-length record All records have exactly the same number of bytes Variable-length record Each record contains a variable number of bytes

SAD/CHAPTER 1022 Figure Fixed Length Record With Provision For Multiple Vendors Potentially Wasted Storage Space

SAD/CHAPTER 1023 Figure Variable Length Record With Provision For Multiple Vendors Indicator for number of Vendor Fields

SAD/CHAPTER 1024 Paging and Blocking Page The actual amount of data read or written into memory Page size The total amount of memory allocated Blocking factor The number of records stored or retrieved for a given query

SAD/CHAPTER 1025 Figure Example of Data Stored With and Without Blocking Record 1 Sector Without Blocking Unused Storage Space Record 5 Record 4 Record 3 Record 2 Record bytes Sector With Blocking

SAD/CHAPTER 1026 Figure Record Spanning Approach Sector 1 Unused Storage Space 512 bytes Sector 2 Record 5 Record 4 Record 3 Record 2 Record 1 Record 6 Part 1 Record 10 Record 9 Record 8 Record 7 Record 6 Part 2 Record 11 Part 1

SAD/CHAPTER 1027 Design and Specifying Files Physical file A grouping of all occurrences of a given record structure Often referred to as a table

SAD/CHAPTER 1028 Table Common File Types and Uses

SAD/CHAPTER 1029 File Access methods Sequential File Access A record is accessed by scanning the file from the beginning until the desired record is found Direct or Random Access The address of the block containing the record is determined and then that block is retrieved

SAD/CHAPTER 1030 File Organization Sequential file Files are organized in ascending order according to the primary key A lookup table is often organized using this method Figure 10-8

SAD/CHAPTER 1031 File Organization Index file An index is created that allows the database application to locate a record The record can be stored in either sequential or random manner Figure 10-9

SAD/CHAPTER 1032 File Organization Direct file Allows a record to be retrieved using a single disk access operation Maximizing retrieval speed is the primary objective Figure 10-10

SAD/CHAPTER 1033 Figure Sequential File Organization Method Physical Record Position in File Record Primary Key

SAD/CHAPTER 1034 Figure Example of Record Lookup Using an Indexed File Organization Approach Master Index Cylinder Index Track Index Track 2 Track 1 Track 3

SAD/CHAPTER 1035 Figure Division-Remainder Hashing Algorithm The general computation for determining a relative storage address slot for a particular record is: Relative slot address = 1 + Remainder of Primary Key Value _ Total Number of Reserved Address Assume a PRODUCT file with 4, 500 unique records. The storage allocation for this file is equal to the number of records, therefore 4,500 storage slots will be needed on the media. The primary key for records in this file is the PRODUCT_ID field. The location for PRODUCT_ID can be computed as follows: Relative slot address = 1 + Remainder of _ = =

SAD/CHAPTER 1036 File Volumetrics Analysts must determine the desired storage space for a given file in the database. The concept of volumetrics is intended to address the question of exactly how much data is needed.

SAD/CHAPTER 1037 File Volumetrics The size of a file is dependent on: Field data type Record structure Storage media employed Block size File organization scheme

SAD/CHAPTER 1038 Table Example of Volumetric Analysis for INVOICE File

SAD/CHAPTER 1039 Designing the Database Database is a coherent and concise source of data for a variety of users and a variety of applications Database management system is the central nervous system of a database

SAD/CHAPTER 1040 Database Architecture Network Hierarchical Relational Object-oriented

SAD/CHAPTER 1041 Network Database Model One of the earliest database architectures Each file in the database may be associated with any number of subordinate or superior files

SAD/CHAPTER 1042 Figure Example of a Network Database Architecture

SAD/CHAPTER 1043 Hierarchical Database Model Links the files in the database in the form of a hierarchy A parent file can have many children, but a child file can have only one parent

SAD/CHAPTER 1044 Figure Example of Hierarchical Database Architecture STUDENT FILE STUDENT FILE ACADEMIC ACTIVITY FILE ACADEMIC ACTIVITY FILE FINANCIAL ACTIVITY FILE FINANCIAL ACTIVITY FILE CURRENT COURSE FILE CURRENT COURSE FILE

SAD/CHAPTER 1045 Relational Database Model Can be visualized as a set of two- dimensional tables or spreadsheets made up of column and rows Files are linked together by relations formed via attributes shared by two files

SAD/CHAPTER 1046 Figure Example of a Relational Database Architecture RELATION A (Primary Key, Attribute 1, Attribute 2, Attribute 3, …) RELATION B (Primary Key, Foreign Key, Attribute 2, Attribute 3, …)

SAD/CHAPTER 1047 Object-Oriented Database Model Encapsulates both the attributes associated with an object and the methods that operate on those objects in a structure referred to as an object class Relationship between object classes are shown by nesting one object class inside another - End -

SAD/CHAPTER 1048 Chapter Summary The effective design of the physical database is a key element in the successful design and implementation of an organizational IS. The skill of designing and implementing the relational database model will remain viable for many years to come.

Chapter 10 End of Chapter