Installing Oracle Enterprise Linux 5 on VMware Server 2

Here are my experiment with installing Oracle Linux Server (Enterprise Edition) on VMware server 2 (free edition).

1. Choose "Create Virtual Machine" on Summary tag.
2. Enter Name of Virtual Machine you want to create, if you have more than one datastore, choose one. click Next.


3. On the radio button choose "Linux Operating" with version "Other 2.6.x Linux (32-bit)"


4. Set virtual Memory and Processors, this setting is depending on the configuration of your PC. if it is finished, click Next.


5. Specify the hard disk space do you want to create.


6. Add the Network Adapter.


7. Use the network bridge.


8. On CD/DVD Drive, specify the source file. If you have the ISO file, choose "Use an ISO", if the source from physical CD/DVD Drive, choose "use a Physical Drive".


9. If you need floopy drive, you can add it. But i dont choose to install it.


10. But in this step i choose to add a USB device. Click next.


11. Finish


12. Turn on the machine.

13. Click at the "Console" tag, then click console to open the console in a new window.

Now you have the host for install the Oracle Linux Enterprise. Then you just follow the installation instruction.

Installing VMware Server 2 in openSUSE 11.0

These are short tutorial for installing VMware Server 2 in openSUSE 11.0:

1. First, check the availability of the prerequisites:
   rpm -qa | egrep "kernel-source|gcc-|make"
   Make sure kernel-source, make, gcc, gcc-c++ already installed, if it's not use YaST to install it.
2. Run this command as root:
   # cd /usr/src/linux
   # make mrproper; make cloneconfig; make modules_prepare
3. Download the VMWare .rpm installer and installed using YaST (just double-click the file). Or in the terminal type, #rpm -ivh .
4. Run configuration script as root:
   # /usr/bin/vmware-config.pL

• accept the licence agreement. (Press enter and the space bar to scroll through and enter q at the end to quit)
• configuration starts and in most cases you can accept the defaults.
• choose "Bridged" for the networking option.
• choose your username when asked: "Please specify the user whom you wish to be the VMware Server administrator".
• if asked "Do you want this program to try to build the vmmon module for your system?", then answer "yes".
• if told that there's a difference between various "gcc" modules and then asked if you want to proceed anyway, then answer "yes".
• finally, enter the software key. (A8H80-PAF8N-0CM9M-4RJ09)

5. Open YaST- System - System Services (Runlevel). Enable vmware in the the "Service" list, leaving the other vmware services alone. In "Expert" mode, vmware is set to runlevels 2, 3 and 5 and the other vmware-related services aren't set for any runlevels. Stop the 4 vmware services (that you see in Yast's System Services [Runlevel]) from running concurrently at boot time. They are supposed to run consecutively. Edit the file /etc/sysconfig/boot and find the line RUN_PARALLEL="yes". Change yes to no. That will cause the startup scripts to run consecutively.

6. Start it manually :
# sudo /etc/init.d/vmware start

7. Open the browser:
http://localhost:<8222>
8222 is default port for VMware server.


That's it..

NORMALIZATION (SECOND)

In this post we will discuss about how to do the normalization. The picture below is an example ER diagram that normalization will be done.

After we learned ER diagram above carefully, then the first thing we will do is called mapping in the form of a table. Note the relationship between the entities and attributes that are in it, because the relationship between entities is important in making the final table later. Then after mapping the results are as follows.

For the normalization phase, the need to do is remove the recurrence occurred on the table. Once we do this before the table is already in the form of 1NF.

A relationship is said to meet the second normal form of relations, when the relation is meet the first normal form, and the attributes that are not key is dependent on the key itself. Seen there on the table of pegawai increased to 2 tables in second normal form.



A relationship is said to satisfy the third normal form relations, when the relation meet the second normal form and he attributes that are not key is not transitive dependent on the key itself. Same as in the second normal form, the changes only on the table pegawai only.



This table is only up to the third normal form only, because it is not possible any longer to reach the next normal form.

NORMALIZATION

In his seminal paper on the relational data model, E.F. Codd formulated a number of design principles for a relational database (Codd, 1970). These principles were originally formalized in terms of three normal forms: first normal form, second normal form and third normal form. The process of transforming a database design through these three normal forms is known as normalization. By the mid-1970s third normal form was shown to have certain inadequacies and a stronger normal form, known as Boyce–Codd normal form (BCNF), was introduced (Codd, 1974). Subsequently Fagin introduced fourth normal form and indeed fifth normal form (Fagin, 1977; 1979).

Normalization process is the establishment of the database structure so that most of the ambiguity can be removed. The normalization of starting the light phase (1NF) to most stringent (5NF). Usually only up to the level of 3NF or BCNF because already sufficient to generate the table-a table of good quality.

1. Why Normalize?

• Optimization table structures
• Increase the speed
• Eliminate income the same data
• More efficient use of storage media
• Reduce redundancy
• Avoiding anomalies (insertion anomalies, deletion anomalies, update anomalies).
• Improved data integrity

2. Stages of Normalization

Normalization is carried out in the following steps:

• Collect the data-set – the set of data-items
• Transform the unnormalized data-set into tables in first normal form
• Transform first normal form tables to second normal form
• Transform second normal form tables to third normal form

Occasionally, the data may still be subject to anomalies in third normal form.
In this case, we may have to perform further steps:

• Transform third normal form to Boyce–Codd normal form
• Transform third normal form to fourth normal form
• Transform fourth normal form to fifth normal form

The process of transforming an unnormalised data-set into a fully normalised (third normal form) database is frequently referred to as a process of non-loss decomposition. This is because we continually fragment our data structure into more and more tables without losing the fundamental relationships between data-items.

2.1 Determinancy/Dependency

Normalisation is the process of identifying the logical associations between data-items and designing a database which will represent such associations but without suffering the file maintenance anomalies.
The logical associations between data-items that point the database designer in the direction of a good database design are referred to as determinant or dependent relationships. Two data-items, A and B, are said to be in a determinant or dependent relationship if certain values of data-item B always appear with certain values of data-item A.
Determinancy/dependency also implies some direction in the association. If data-item A is the determinant data-item and B the dependent data-item then the direction of the association is from A to B and not vice versa. There are two major types of determinancy or its opposite dependency: functional (single-valued) determinancy, and non-functional (multi-valued) determinancy. We introduce here the concept of functional determinancy. Non-functional determinancy is discussed below.
Data-item B is said to be functionally dependent on data-item A if for every value of A there is one, unambiguous value for B. In such a relationship data-item A is referred to as the determinant data-item, while data-item B is referred to as the dependent data-item. Functional determinancy is so-called because it is modelled on the idea of a mathematical function. A function is a directed one-to-one mapping between the elements of one set and the elements of another set.


2.2 Unnormalized Data-Set to First Normal Form

The data-set represented in tabular form in section 18.2 is said to be an unnormalized data-set. This can be seen, for instance, if we choose the data-item moduleName as the key of this data-set and underline it to indicate this. Realistically, if we remove redundant information, we should represent the information as follows:



A given cell of the table for the attributes studentNo, studentName, assGrade and assType contains multiple values. Examining the table above we see that studentNo, studentName, assGrade and assType all repeat with respect to moduleName.

A relation is in first normal form if and only if every non-key attribute is functionally dependent upon the primary key

The attributes studentNo, studentName, assGrade and assType are clearly not functionally dependent on our chosen primary key moduleName. The attributes staffNo and staffName clearly are. This means that we form two tables: one for the functionally dependent attributes, and one for the non-dependent attributes. We declare a compound of moduleName, studentNo and assType to be the primary key of this second table.



2.3 First Normal Form to Second Normal Form

To move from first normal form to second normal form we remove part-key dependencies. This involves examining those tables that have a compound key and for each non-key data-item in the table asking the question: can the data-item be uniquely identified by part of the compound key?

A relation is in second normal form if and only if it is in first normal form and every non-key attribute is fully functionally dependent on the primary key

Take, for instance, the table named Assessments. Here we have a three-part compound key moduleName, studentNo and assType. We ask the question above for each of these data-items in relation to the non-key data-items studentName and assGrade. Clearly we need all the items of the key to tell us what the assessment grade is. ModuleName however has no influence on the
studentName. StudentNo alone determines studentName. Hence, we break out the determinant and dependent data-items into their own table. This leads to a decomposition of the tables as follows:



2.4 Second Normal Form to Third Normal Form

To move from second normal form to third normal form we remove inter-data dependencies. To do this we examine every table and ask of each pair of non-key data-items: is the value of data-item A dependent on the value of data-item B, or vice versa? If the answer is yes we split off the relevant data-items into a separate table.

A relation is in third normal form if and only if it is in second normal form and every non-key attribute is non-transitively dependent on the primary key

The only place where this is relevant in our present example is in the table called Modules. Here, staffNo determines staffName. StaffName is hence transitively dependent on moduleName. StaffNo is therefore asking to be a primary key. Hence, we create a separate table to be called Lecturers with staffNo as the primary key. This is illustrated below:




2.5 BCNF

BCNF is a stronger normal form than third normal form, designed to cover anomalies that arise when there is more than one candidate key in some set of data requirements.

Example:
Suppose we have introduced a scheme of majors and minors into our degree schemes at a university. The business rules relevant to that part of this domain covering majors are listed below:

• Each student may major in several areas
• A student has one tutor for each area
• Each area has several tutors but a tutor advises in only one area
• Each tutor advises several students in an area

A diagram incorporating all these business rules is given in figure below.



On the basis of these business rules, a schema is produced in third normal form, represented in the bracketing notation below:

Majors(studentNo, area, staffNo)

A set of sample data is provided in the table below.



This schema is in third normal form because there are no partial dependencies and no inter-data dependencies. However, anomalies will still arise when we come to update this relation. For instance:

• Suppose student 123456 changes one of his or her majors from computer science to information systems. Doing this means that we lose information about staffNo 234 tutoring on computer science. This is an update anomaly.
• Suppose we wish to insert a new row to establish the fact that staffNo 789 tutors on computer science. We cannot do this until at least one student takes this area as his or her major. This is an insertion anomaly.
• Suppose student 345678 withdraws from the university. In removing the relevant row we lose information about staffNo 567 being a tutor in the area of information systems. This is a deletion anomaly.

These anomalies occur because there are two overlapping candidate keys in this problem. R.F. Boyce and E.F. Codd identified this problem and proposed a solution in terms of a stronger normal form known as BCNF. A relation is in BCNF if every determinant is a candidate key. The schema above can be converted into BCNF in one of two ways. The two schemas are presented in bracketing notation below:

Schema 1:
StudentTutors(studentNo, staffNo)
TutorAreas(staffNo, area)
Schema 2:
StudentTutors(studentNo, area)
TutorAreas(staffNo, area)

2.6 Fourth and Fifth Normal Form

Relations in the fourth normal form (NF 4) if the relation in BCNF and does not contain a lot of dependence values. To remove the dependency of many values from a relation, we divide the relationship into two new relations. Each relation contains two attributes that have a lot of relationship value.
Relations in fifth normal form (5NF) deal with a property called 'join' without any loss of information (lossless join). Fifth normal form (also called the 5 NF PJNF (projection join normal form). The case is very rare and appear difficult to detect in practice.

DATABASE AND E-R DIAGRAM

1. Database Definition

The database (English language: a database), or often also spelled database, is the collection of information stored in the computer so that it can be systematically examined using a computer program to obtain information from the data base. Software used to manage and call the query (query) of data base is called the database management system (DBMS).
Basic concept of the database is a collection of records, or snippets of knowledge. A database has a structured explanation of the types of facts stored in it: this description is called the scheme. Scheme describes the objects that represented a data base, and the relationship between these objects. There are many ways to organize the scheme, or structure model of the database: this is known as the database model or data model. Model that is now commonly used relational model, according to Layman: the term represents all the information in the form of table-related tables where each table consists of rows and columns (using the definition of the actual mathematical terminology). In this model, the relationship between the table represented by using the same value across the table. The other models, such as the hierarkis network model and use a more explicit way to represent relationships between tables.


2. Database Management System

A Database Management System (DBMS) is an organised set of facilities for accessing and maintaining one or more databases. A DBMS is a shell which surrounds a database or series of databases and through which all interactions take place with the database. The interactions catered for by most existing DBMS fall into four main groups:
a. Data definition – defining new data structures for a database, removing data structures from the database, modifying the structure of existing data.


b. Data maintenance – inserting new data into existing data structures, updating data in existing data structures, deleting data from existing data structures.
c. Data retrieval – querying existing data by end-users and extracting data for use by application programs.
d. Data control – creating and monitoring users of the database, restricting access to data in the database and monitoring the performance of databases.


3. Data Definition

A database is effectively a set of data structures for organising and storing data. In any data model, and consequently in any DBMS, we must have a set of principles for exploiting such data structures for information systems applications within organisations. Data definition is the process of exploiting the inherent data structures of a data model for a particular organisational application.

3.1 Relations

There is only one data structure in the relational data model – the relation. Because the idea of a relation is modelled on a mathematical construct, a relation is a table which obeys a certain restricted set of rules:

• Every relation in a database must have a distinct name.
• Every column in a relation must have a distinct name within the relation.
• All entries in a column must be of the same kind. They are said to be defined on the same domain.
• The ordering of columns in a relation is not significant.
• Each row in a relation must be distinct. In other words, duplicate rows are not allowed in a relation.
• The ordering of rows is not significant.
• Each cell or column/row intersection in a relation should contain only a socalled atomic value. In other words, multiple-values are not allowed in the cells of a relation

3.2 Primary Key

Each relation must have a primary key. This is to enforce the property that duplicate rows are forbidden in a relation. A primary key is one or more columns of a table whose values are used to uniquely identify each of the rows in a table. In any relation there may be a number of candidate keys; that is, a column or group of columns which can act in the capacity of a unique identifier. The primary key is chosen from one of the candidate keys.
Example:
Consider the relation named Lecturers above. The attributes staffNo, staffName and status are currently candidate keys since the values in these columns are currently unique. We know in practice, of course, that as the size of the lecturers table grows, we may store information about more than one lecturer named Evans R, and more than one lecturer is likely to be a senior lecturer – an SL. This leaves staffNo – a unique code for each lecturer of a university – as the only practicable primary key.

Any candidate key, and consequently any primary key, must have two properties. It must be unique, and it must not be null – a special character being used to indicate a missing or incomplete datum. First, by definition any candidate key must be a unique identifier. Hence, there can be no duplicate values in a candidate or primary key column. Second, we must have a primary key value for each row in a table. In other words, we cannot have a null (non-existent)
value within a primary key column or columns. Picture below is example of primary key.



3.3 Domains

The primary unit of data in the relational data model is the data-item. Such data-items are said to be non-decomposable or atomic. A set of such data-items of the same type is said to be a domain. Domains are therefore pools of values from which actual values appearing in the columns of a table are drawn.
Example:
Examples of data-items include a staff number such as 244, a lecturer name such as S Patel or a student’s date of birth such as 1/7/1986. Suppose there are four members of staff in our institution with the staff numbers 244, 386, 534 and 222. The domain of staff numbers is the set of all possible staff numbers, in our case {244, 386, 534, 222}.

3.4 Foreign Key

Foreign keys are the means of interconnecting the data stored in a series of disparate tables. A foreign key is a column or group of columns of some table which draws its values from the same domain as the primary key of some related table in the database.
Example:
Consider the relation named Lecturers above. staffNo is a foreign key in the modules table. This column draws its values from the same domain as the staffNo column – the primary key of the lecturers table. This means that when we know the staffNo of some lecturer we can cross-refer to the lecturers table to see, for instance, the status of that lecturer.

3.5 Super Key

Superkey is one or more attributes of a table that can be used to identify the entity / record from the table which are unique (not all attributes can be superkey).

3.6 Candidate Key

Candidate Key is a super key with minimal attributes. Candidate must not contain a key attribute of the table so that the other candidate key is certain superkey but not necessarily vice versa.


4. Entity Relationship Model

Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion.

Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short. The definitive reference for entity relationship modelling is generally given as Peter Chen's 1976 paper^[1]. However, variants of the idea existed previously (see for example A.P.G. Brown^[2]) and have been devised subsequently.

5. Data Models

5.1 Entities

An entity may be defined as a thing which an organisation recognises as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world. An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen (1976) we should really distinguish between an entity and an entitytype.
An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. It must be remembered however that whenever we refer to an entity we normally mean an entity-type. Entities are by their very nature interesting things because entities are normally used to define logical data groupings. In conventional information systems jargon the term logical data grouping normally means a file. One rule of thumb to apply in identifying suitable entities for a given application is therefore the following:

If you need to store data about many properties of some thing, then that thing is likely to be an entity.

5.2 Relationship
A relationship is some association between entities. In this section we shall concentrate on binary relationships. That is, associations between two entities. In section 16.4 we shall introduce other N-ary relationships. That is, relationships between one, three, four or N entities. In the E–R approach, more than one relationship can exist between any two entities.

5.3 Attributes

As a real-world aspect, an entity is characterised by a number of properties or attributes. Values assigned to attributes are used to distinguish one entity from another. We also choose one or more attributes to act as identifiers for instances of an entity.

This picture below is the examples of entities, relationship, and attributes.



6. Cardinality

Cardinality (or degree) concerns the number of instances involved in a relationship. A relationship can be said to be either a 1:1 (one-to-one) relationship, a 1:M (one-to-many) relationship, or a M:N (many-to-many) relationship.
Example:
The relationship between a Bankaccount entity and a Customer entity can be said to be one-to-one (1:1) if it can be defined in the following way:

A bank account is held by at most one customer
A customer may hold at most, one bank account

In contrast, the relationship between Bankaccount and Customer is one-to-many (1:M) if it is defined as:

A customer holds many bank accounts
A bank account is held by at most one customer

Finally, we are approaching a realistic representation of the relationship when we describe it as being many-to-many (M:N). That is:

A customer holds many bank accounts
A bank account may be held by many customers

The other example of Cardinality:




7. E-R Notation