Instructions:

two written paragraphs for each numbered question, 10 sentences per paragraph.

providing good support from Chapter 6 helps strengthen your answer, opinions are welcomed.

1. what type of information wonder could possibly occur to allow someone to be buried in the wrong clothes, coffin, and plot?

2. what could the cemetery do to ensure its customers are burried in the correct places?

3. why is the quality of information important to any business?

4. what issues can occur when a business uses low-quality information to make decisions? Chapter 6 Notes;

Information granularity is a measure of how detailed something is. If you look at the chart in your chapter on this topic, youll see that they categorize it as Fine, Summary and Aggregate. Much of our data in databases is stored at the aggregate level, simply because it takes less space. To get it to the aggregate state, the data is rolled up from the detail level. For instance, if you have daily sales data for 4 weeks, you would want to summarize that data and store it at the weekly level, then perhaps summarize it further and store it at the monthly levelas we aggregate upwards, or roll the data up, we go from monthly to quarterly to yearly. It makes much more sense to save data at the yearly level, then explode it downwards to the more detailed level for viewing and querying.

Information formats refers to different types of information and how its stored. Whether its a basic document, or the visual display of a presentation, or the columnar format of a spreadsheet, or a complete database, which could hold files in all of those formats its to our best interest to know how to use all of these formats in business to our best advantage.

The issue of information level becomes important when dealing with information systems, as it is necessary to differentiate between enterprise-wide software, departmental software and software for individuals. In some cases, systems will transcend ALL these levels, but different processes work at different levels so it becomes critical to be able to identify the different areas.

Your book talks about transactional and analytical information. Transactional information is all the information contained in a business process or activity. It refers to all the data coming from daily operational tasks. Analytical information has more of a wider corporate focus and is rooted in analytical models and systems, utilizing transactional data.

Databases

The creation of the database is one of the most significant effects of the technological revolution to impact corporations, bar none. Prior to the idea of a centralized database, corporation architecture looked much like what we see below:

This chart shows some of the corporate departments with their individual departmental databases. As you look at this graphic, one question comes to mind. With no common database, how do companies share data? Also, with this many individual databases, how many times is the same data entered? While each department will have its own type of data to enter, every department will also have common corporate data, such as revenue, costs, etc. that must be entered. In this example we have 8 departments how many times will that data be entered? How many typos will be made? What is the overall quality of this corporations data? Suppose you were a manager in this company your VP comes to you and calls you in for a meeting, along with the other departmental managers he wants to know the state of the union, more or less. When each of you get done reporting your figures and none of them match, what do you think the VP is thinking? Who is he to believe? You can see the problems that would arise in this scenario. Now look at the same corporation below, with the addition of a central database. You can clearly see how easily EVERYONE had access to the SAME information. The data is entered in ONE time, by the Database Administrator (DBA), who is in charge of the centralized database. In fact, even though each department can view the data, NO ONE is allowed to edit it in any way, except for the DBA. Thats how companies maintain the quality of the data. Most companies usually opt to purchase a data warehouse as their centralized database, simply because it can hold much more data. We will be discussing that type of database in the next chapter.

The relational database structure, which is the most common of structures, but is not always the only structure used. The oldest form of database structure is the hierarchical structure, which is used for very narrow database queries meaning that the database searches dont involve many entities. The graphic below shows a hierarchical type structure, otherwise known as a tree structure:

As you look at this structure, you can see that it shows who is working on 2 projects in the IS Dept. We know that Tom, Sue and Jim are working on Project A. Imagine that when this hierarchy was first set up, Tom probably only had one project that he was working on well assume its project A. To query the database for information on Tom and Project A, there is no problem it is a straightforward query. But what happens if we want to now add information about Project B? There is no connection at the end of the tree to link Project B to Project A. The database has to do all the way back up to the root (IS Dept) and back down the tree to access information about Tom in Project B. That takes more time. Thats what I meant when I said that the hierarchical structure is great for short, NARROW queries it can even be faster than the relational structure. But as soon as you start adding too many DISCONNECTED entities, the query time increases rapidly. Companies, however, do still use these structures, depending on the type of queries needed.

The relational structure is based on the idea of tables. Many of you have used Access before, which is relational in structure and based on creating tables, then linking those tables into relationships. This is the most common type of structure and produces the fastest queries, when there are many entities to search. Please read about these in your text.

The most important thing to understand about both of these structures, is that the decision as to which structure will be the cornerstone of the database depends on one thing how the USER will be conducting queries. The only reason to have a database to begin with is so that we can get information OUT of it. We dont have databases simply to collect data and look pretty. Prior to the creation of a database, the DBA will sit down with ALL users, from ALL departments, and find out the type of information they need, HOW they plan on accessing it, what kind of reports theyll be running, etc. The DBA needs to know this BEFORE the database is created or purchased, in order to structure it according to what users want. If users wont use it its pointless. It can take up to 3 years to create databases or data warehouses in large corporations at least half of the time is spent interviewing users throughout the company as to their needs.

Querying a Database

Querying a database has become greatly simplified over the years. Most company users use a standard query software such as SQL (Structured Query Language) to write their queries. For any of you that have ever used Access you have been using SQL when you drag and drop fields to create your queries. Necessary to any querying, are 2 documents that most companies have on their intranets: the data dictionary and the logical schema.

The data dictionary lists out alphabetically, all the fields in a database and information about those fields how many characters the field name is, what type of field it is (character, text, logical or numeric), what table the field is location in, etc. The DBA creates this data dictionary and makes it available to all users. The file is read-only of course.

The logical schema gives information on the database but in a slightly different format. Instead of listing all fields alphabetically it shows pictures of tables as rectangles and the relationship between those tables graphically the fields for each table are shows within the rectangles. While a schema does not give the detail that a data dictionary can, it can be handy to see the tables at a glance and the fields within.

Users need these documents when creating a query, because as field names are specified in a query, if a user spells a field name wrong, the database will not return any information because it couldnt find the right field to search.

Integrity Constraints

Your text talks about relational integrity constraints and business-critical constraints-- be sure you understand the difference between these. The relational integrity constraint is a basic common-sense, logical constraint i.e. not being able to create an order for a customer that doesnt exit. A business-critical constraint is particular to a companys business rules that are set by management i.e. no product returns can be logged if its after 15 days from date of purchase.

Data Warehousing

As was mentioned in the previous notes, data warehouses are usually the database of choice for most companies, due to the fact that they can hold such a huge volume of data. But most companies are faced with a couple of choices, when deciding to go with a data warehouse whether to purchase a complete package or design many of the components in-house. A data warehouse management system is composed of 3 main components:

-- database

-- query (knowledge management tool)

-- loader software

While the purchase of the database is usually a given, some companies opt to design their own query management systems and/or loader software. The query management tool, or knowledge management tool, as it is sometimes called, sits on the front end of the database and is used for querying the database. These tools are usually very user friendly, frequently comprised of drag and drop menus to pull fields in for an SQL query.

Loader software is a program that sits on the front end of the database as well checking all incoming feeds to make sure that the data coming into the database from external sources is in the proper format. An example of this would be when a vendor is making electronic payments to its account the incoming data will need to populate that vendors table in the specific order that the table is set up in. For instance, Company X is sending a payment in to AT&T, lets say. The payment comes in during the early morning hours, when there is less traffic on the system. The loader will check this incoming data stream to make sure it matches up with the format of the table below it will check to makes sure that the fields are in the proper order, as well as if the field length matches. If the table specifies that Co_Code is 4 characters, that same field in the incoming feed needs to be the EXACT same length. If it isnt, it throws off the entire input.

Co_Code	Co_Name	Product_Code	Product_Name	Date

Company Xs Table

When there are problems, in most cases the loader software can detect it, stop the feed and send back an error message to the vendor. However, if the error occurs deep into the feed, the loader can sometimes crash, because its already accepted most of the feed and has trouble reversing the process. When this happens, it becomes a critical issue, as the loader shuts down for ALL feeds, causing huge problems with other vendors trying to send in their payments. Most companies, if possible, prefer to design their own loaders (if they have loader programmers on staff), because they can call out their programmers at 3 am and get the problem fixed ASAP. If a company chooses to purchase a loader program, chances are theyll be waiting until the next day or later, before the problem is fixed. At AT&T Wireless, they opted to purchase the database and query management tool, while designing the loader themselves.

One of the main advantages of developing or buying a data warehouse is for the tremendous analysis opportunities that it affords. All data warehouses come with data mining tools built in a variety of statistical packages designed to analyze huge volumes of data. Most are very user friendly. Marketing research departments use these tools to discover hidden trends in customer data, as well as discover different associations or customer preferences, based on sales data analyzed. When you think of data warehouse, you should immediately think analysis.

the lid of her coffin during the funeral to discover another woman lying in her clothes and jew Information--you simply can't put a value on having the right (or the cost of having the wrong information. Just look at the mistake made at the Crib Point cemetery in Victoria, Australia, when they were burying Mrs. Ryan, an 85-year-old woman with almost 70 children, grandchildren, and 9. That Is Not My Mother in the Casket elry . Where was the body of Mrs. Ryan? Mrs. Ryan had been buried earlier that day in the other woman's clothes, jewelry, and plot. What type of information blunder could possibly occur to alon someone to be buried in the wrong clothes, coffin , and plot? What could the cemetery do to ensure its customers are buried in the correct places? Why is the quality of information important to any business? What issues can occur when a business uses low-quality information to make decisions the lid of her coffin during the funeral to discover another woman lying in her clothes and jew Information--you simply can't put a value on having the right (or the cost of having the wrong information. Just look at the mistake made at the Crib Point cemetery in Victoria, Australia, when they were burying Mrs. Ryan, an 85-year-old woman with almost 70 children, grandchildren, and 9. That Is Not My Mother in the Casket elry . Where was the body of Mrs. Ryan? Mrs. Ryan had been buried earlier that day in the other woman's clothes, jewelry, and plot. What type of information blunder could possibly occur to alon someone to be buried in the wrong clothes, coffin , and plot? What could the cemetery do to ensure its customers are buried in the correct places? Why is the quality of information important to any business? What issues can occur when a business uses low-quality information to make decisions