Database Management Systems (DBMS) and Data Mining

 Question One

Database management systems (DBMS) and data mining are very crucial components in the improvement of service delivery in any business. However, representation of data is done using different tables in both cases. For instance, there two major types of tables used in presenting data both in DBMS and data mining (Olive, 2007). Nested tables are where a single customer has different items. However, a nested table representation is done within the case table in form of a special column having a data type of table. Therefore, these types of tables usually contain rows selected from the parent table for any particular case row. Nested tables have very crucial use since data contained in them can be used for input or for prediction, or sometimes for both. For instance, it a model two nested table columns might be present whereby one of them might contain a list of items purchased by a customer, whereas the other might be containing information concerned with other particulars of the customers probably obtained from a survey (Olive, 2007). Therefore, in this case the company may use the particulars of their customers such as interests and hobbies as an input to facilitate analysis of the customers’ purchasing behaviour as well as aiding predicting of future purchases.

The other type of table is the relational table whereby relationships between customers and items are carried out. Moreover, relational tables are also very essential in storing data in the database management system in the form of tables which are related. A relational table contains information or data which is fitted into categories which are predefined, and sometimes the data categories may be one or more. Moreover, every row contains a particular categories’ data which is column defined (Olive, 2007). For instance, in relational tables a typical database for business order entries would include columns for representing customer information such as address, name, phone number, and others while another table would represent the description such as the product, sales price, and date. Hence they would be used to relate customer information and the order information.

Question Two

Cardinality constraints constitute one of the most significant types of constraints faced in conceptual modelling. This is due to the fact that despite its ability to constrain the population of relationship types, it is also very helpful in helping us in understanding the meaning of the involved types thereby playing a very crucial role in the design of database management systems. However, there are four major cardinality constraints such as optional one, mandatory one, optional many and mandatory many whereby all of them are differently used (Olive, 2007).

However, there are various personal examples of the four cardinality constraints listed above. For instance, the best personal example of the first cardinality constraint which is the optional one is for a person to own a bicycle which is absolutely optional because it is not a must to own a bicycle. The example for the second cardinality constraint which is the mandatory one is for any team to have a leader. This is due to the fact that no team can lead itself hence for its optimal performance a leader must be there. However, an example for the third cardinality constraint which is the optional many is a registering for a course whereby a student often chooses which course to register for among many which are present. Finally, an example for the last cardinality constraint which is mandatory many is the use of textbooks by student taking a course (Olive, 2007). This is mainly because for successful completion of the courses selected by the student textbooks must be used. Hence since different course are selected by the students at the beginning of every semester, this cardinality constraint fits into the mandatory many category.

Question Three

For effective management of information systems in a company it is necessary to be able to select primary key from candidate keys. However, this follows the process of the candidate keys to meet three absolute demands to be regarded a primary key. Therefore, candidate keys meet three fundamental demands and any deviation indicates that it becomes a primary key. For example, 1) a candidate key is always unique within its domain; 2) candidate key can not hold NULLs, that is, those with unknown value; and 3) candidate key is never expected change meaning it must hold the same value throughout the lifetime of an entity for a given occurrence (Olive, 2007). This means that in 1, the candidate key has the main purpose of helping us in the identification of one single row in a table irrespective of those which exists thereby setting high demands on the keys flexibility. However, in 2, it is always important for a candidate key to hold a value. Moreover, in 3, the value of candidate keys is not allowed to change irrespective of what happens outside and inside the business. Therefore, in a situation where the candidate key is capable of withstanding all the above discussed three demands, then it’s important to note that the primary key has been selected or identified (Olive, 2007).

In most cases the foreign keys relate to candidate keys from the fact that both are used in the relational model of databases, whereby the candidate key is a minimal super key for the indication of the existing relation, while a foreign key can be referred as a referential constraint that matches another table’s candidate key (Olive, 2007). A good example is where a customer table consists of the data for all customers while an order table consist of all orders placed by the customers. In this case, both candidate keys and foreign keys must be used to determine the relationships which exist.

Question Four

There are three levels of database architecture allowing for the information to be a clearly separated such as the external (individual user view), internal (storage or physical view), and conceptual (community user view). Hence a database system capable of separating these three views of data which are different is in most cases flexible and adaptable because of the data independence (Olive, 2007). However, there are circumstances which allows breakdown of the overall design of data into the individual user view. This is mainly because it often presents a database’s restricted view.  The other circumstance of using the individual user view is that, the end users as well as the programmers of the application are only interested in the database’s subset (Olive, 2007). For example, a head of department in a university or college may only be interested in the student enrolments and departmental finance but not the information about the library. On the other hand, a librarian is not envisaged to have any interest in the academic staff information. This creates the need for individual user view whereby every person sees what is of interest to him or her.

Reference

Olive, A. (2007). Conceptual Modelling of Information Systems. New York, NY: Springer.