More Related Content
Viewers also liked
Viewers also liked (7)
More from ljmcneill33
More from ljmcneill33 (20)
Recently uploaded
Recently uploaded (20)
Hi600 u11_inst_slides_ch11
- 1. HI-600: Analysis and Design of Health Information Systems Design: Part V Data Storage Design
- 3. FROM LOGICAL TO PHYSICAL DATA MODELS
- 4. Revising the CRUD Matrix
- 5. OPTIMIZING DATA STORAGE • Storage Efficiency • No redundant data: normalization • Speed of Access • Denormalization • Clustering • Indexing • Estimating the size of data for hardware planning
Editor's Notes
- Hello everyone, Welcome to the last lecture of the design phase. After covering system acquisition techniques, hardware and software specifications, user interface design, and program design, this week we will briefly talk about data storage design in general, only emphasizing physical data modeling and then we will cover a different approach to system design, namely object oriented approach. the Health Informatics students will cover databases in detail next semester in HI-601 Database Theory, Design and Modeling course. At the completion of the design phase the system specification document is composed, which includes alternative matrix, architecture design, hardware and software specification, interface structure design and interface prototypes, physical process model and program design specifications, and physical data model and data storage design specifications. Data storage design activities are composed of various implementation decisions regarding how data is stored and handled by programs that run the system. This includes - selecting the data storage format; - converting the logical data model created during analysis into a physical data model to reflect the implementation decision; - ensuring that DFDs and ERDs balance; and - and finally designing the selected data storage format to optimize its processing efficiency.
- There are two types of data storage formats: files and database - Files are electronic lists of data that have been optimized to perform a particular transaction. Typically, files are organized sequentially, and records can be associated with other records by pointers. Most modern systems use combination of files and database and pointers to the files are stored in the database. - Database is a collection of groupings of information that are related to each other in some way. Databases are managed by Database Management Systems (DBMS) that are software that create and manipulate the databases. End-user DBMSs such as MS Access support small databases, whereas enterprise DBMSs support large scale databases. There are several database types in terms of how they store and manipulate data: legacy databases are based on older technology that is seldom used to develop new applications. Two major types of legacy databases include - Hierarchical databases that use hierarchies, or inverted trees, to represent relationships - and network databases that are collections of records that are related to each other through pointers. On the other hand relational databases are the most popular kind of databases for application development today. A relational database is based on collections of tables, each of which has a primary key. The tables are related to each other by the placement of the primary key from one table into the related table as a foreign key. Most relational database management systems (RDBMS) support referential integrity, ensuring that values linking the tables together are valid and correctly synchronized and Structured Query Language (SQL) is the standard language for accessing the data in the tables. As we will see in the second lecture this week, object-oriented approach is a relatively newer way of analyzing and designing systems. The object database, or object-oriented database, is based on the premise of object orientation that all things should be treated as objects that have both data (attributes) and processes (behaviors). Changes to one object have no effect on other objects because the attributes and behaviors self-contained, or encapsulated, within each one, which allows objects to be reused. In object databases, the combination of data and processes is represented by object classes and an object class can contain a variety of subclasses. Object-oriented database management systems (OODBMS) are mainly used to support multimedia applications or systems that involve complex data, meaning multimedia and text and numeric data together. Hybrid OODBMS technology includes databases with both object and relational features. A multidimensional database is a type of relational database that is used extensively in data warehousing, which is the practice of taking and storing data in a large database that supports decision support systems (DSS). A multidimensional database stores data to support aggregations of data on multiple dimensions. And when the data are first loaded into a multidimensional database, the database precalculates the data across the multiple dimensions and stores the answers for fast access. Each of the file and database data storage format has its strengths and weaknesses and selection of storage formats for a system would consider the data types to be stores (simple text, numeric, date and time; or multimedia data, or aggregate data), the type of application system (whether just transaction processing or a decision support system (DSS)), already existing storage formats, and future needs of the organization.
- Next, let us see how we move from logical data models that we talked about during the analysis phase to the physical data models in the design phase. The logical entity relationship diagrams (ERDs) that were created during analysis depict the “business view” of the data, but omit implementation details. Having determined the data storage format, physical data models are created to show implementation details and to explain more about the “how” of the final system. The ERD contains the same components for both logical and physical models, including entities, relationships, and attributes. The difference lies in the fact that physical ERDs contain references to how data will be stored and that much more metadata are defined. The transition from the logical to physical data model involves five steps : First, we change entities of logical ERD to into tables or files depending on what data storage format we have determined. In this step a naming convention is established for tables, files, and fields so that the names reflect the actual names of the system components when they are implemented. Also in this step, metadata for tables and files are updated to include implementation details, such as expected sizes of tables and files. Next, we change attributes to fields. Fields are columns in files or tables. Then data dictionary is updated to include more metadata such as field’s data type, length, default value, and valid value. Data type and length actually are displayed on the Entity Relationship Diagram, right after the field names as we see on this example. Some of the most common data types include integer, decimal, long-integer, character, date, time, date-time, and boolean. A default value specifies a value that should be placed in a field if no value is specified when inserting a record to a table. And a valid value is a fixed list of values or an expression of data validation code for a particular column. Next, the identifying attributes of logical ERD are converted into primary keys of the physical ERD. Unlike logical ERDs, primary keys are mandatory for physical ERDs. So, if none of the attributes or their concatenation seem like they can uniquely identify a record, then a system-generated primary key is created, where the system automatically assigns a sequential ID number for each record. In order to be able to technically define relationships of a logical ERD, a technique called foreign key is used to maintain the association between two related tables. A foreign key is the primary key(s) from one table that is repeated in another table to provide a common field between the two tables. This common filed(s) contain values that match a record in one table to a record in the other. In the example on this slide, Lawn Chemical Applicator ID and Chemical ID from Lawn Chemical Applicator and Chemical tables are repeated in the Chemical Request table as foreign keys. As a final step, just like we did for DFDs, system related tables, fields and relationships are added to reflect special implementation needs. As we mentioned before, balance between process and data models should be maintained for the physical models as it was maintained for the logical models. Therefore, implementation-specific data stores, data elements, and data flows from physical DFDs must be included in physical ERD.
- As I said, the balance between process and data models must be maintained. In design, as these models are converted into physical models, changes in the form of new processes, new data stores, and new data elements may occur. Therefore, the CRUD matrix that was created for the logical models should be revised.
- We have selected the data storage format and designed how it should be implemented, now the data storage format should be optimized for processing efficiency. I will just introduce some of the optimization concepts here and leave the details to HI-601 database course. There are two primary dimensions in which to optimize a relational database: for storage efficiency and for speed of access The most efficient tables in a relational database in terms of storage space have no redundant data and very few null values. Normalization is the best way to optimize data storage for efficiency. After having optimized the data model design for data storage efficiency, the end result is that data are spread out across a number of tables. For a large relational database, we also need to optimize access speed for the system to work efficiently. To achieve higher access speeds, one of the things we can do is to denormalize the data by adding some of the redundancy back to the relational database only where it results in significant increase in data access speed. Another technique to increase data access speed is clustering, which is placing records together physically, so that like records are stored closer to each other within a table or across tables. Indexing is another very efficient technique to increase data-access speed. Similar to index of a book, index of a data storage is a minitable that includes values and their locations from one or more columns in a table. Finally, the hardware should be optimum for speed and capacity, so that storage efficiency and access-speed improvements would pay off. With that we conclude the design phase. Next we will look at the object-oriented approach to system analysis and design. And starting from next week, we will move into the implementation phase.