INSTITUTIONAL TRAINING

REPORT ON

ORACLE FOUNDATION ASSOCIATE DATABASE

Submitted by:

Akanksha singh(22BCC70096)

Submitted to :

Mr. Jagjit Singh ( Senior Technical Trainer )

( In partial fulfillment for the award of the degree of )

BACHELORS OF ENGINEERING
IN

COMPUTER SCIENCE WITH SPECIALIZATION IN

CLOUD COMPUTING

Chandigarh University

June 2023
 CONTENT
1. Introduction to Databases
2. Types of Database Models
3. Relational Databases
4. Conceptual and Physical Data Models And characterstic
5. Advantages and Disadvantages of Data Model:
6. Entity and Attributes
7. Types of Entity
8. Types of Entity type
9. Entity Set
10.Attributes
11.Types Of Attributes
12.Relationships
13.Types of relationships
14.Entity Relationship Modeling (ERDs)
15.Database troubleshooting:
16.The components and features of an ER diagram
17.ERD symbols and notations
18.Refining the Data Model
19.What is Database Normalization?
20.What is Composite Key?
21.BCNF (Boyce-Codd Normal Form)
22.What is data modeling and mapping?
23.Data vs. Information
24.History of the Database Timeline
25.Database Development Process.
26.Major Transformations in Computing, History of Computer Systems
27.The Problem of Isolated, Nonintegrated Systems
28.Cloud Computing:
29.Entities, Instances, Attributes, and Identifiers
30.Entities and Instances
31.What is an Entity Relationship Model?
32.Goals of ER Modeling
 Introduction to Databases
A database, in the most general sense, is an organized collection of data. More specifically, a database is an electronic system that
allows data to be easily accessed, manipulated and updated.
In other words, a database is used by an organization as an electronic way to store, manage and retrieve information. The database is
one of the cornerstones of enterprise IT, and its ability to organize, process and manage information in a structured and controlled
manner is the key to many aspects of modern business efficiency.

Types of Database Models

1. Hierarchical database model.

2. Relational model.
3. Network model.
4. Object-oriented database model.
5. Entity-relationship model.
6. The object-relational model, which combines the two that make up its name

1. Hierarchical model :- The hierarchical model organizes data into a tree-like structure, where each record has a single parent or
root. Sibling records are sorted in a particular order. That order is used as the physical order for storing the database. This model is
good for describing many real-world relationships.

2. Relational model :- The most common model, the relational model sorts data into tables, also known as relations, each of which
consists of columns and rows. Each column lists an attribute of the entity in question, such as price, zip code, or birth date. Together,
the attributes in a relation are called a domain. A particular attribute or combination of attributes is chosen as a primary key that can
be referred to in other tables, when it’s called a foreign key.

3. Network model :- The network model builds on the hierarchical model by allowing many-to-many relationships between linked
records, implying multiple parent records. Based on mathematical set theory, the model is constructed with sets of related records.
Each set consists of one owner or parent record and one or more member or child records. A record can be a member or child in
multiple sets, allowing this model to convey complex relationships.
 4. Object-oriented database model :- This model defines a database as a collection of objects, or reusable software elements,
with associated features and methods.

There are several kinds of object-oriented databases:

 A multimedia database incorporates media, such as images, that could not be stored in a relational database.
 A hypertext database allows any object to link to any other object. It’s useful for organizing lots of disparate data, but it’s not ideal for
numerical analysis.

5. Entity-relationship model :- This model captures the relationships between real-world entities much like the network model, but
it isn’t as directly tied to the physical structure of the database. Instead, it’s often used for designing a database conceptually.
Here, the people, places, and things about which data points are stored are referred to as entities, each of which has certain attributes
that together make up their domain. The cardinality, or relationships between entities, are mapped as well.

6. Object-relational model :- An object–relational database can be said to provide a middle ground between relational databases
and object-oriented databases. In object–relational databases, the approach is essentially that of relational databases: the data resides
in the database and is manipulated collectively with queries in a query language; at the other extreme are OODBMS in which the
database is essentially a persistent object store for software written in an object-oriented programming language, with a
programming API for storing and retrieving objects, and little or no specific support for querying.

Relational Databases

A relational database organizes data into rows and columns, which collectively form a table. Data is typically structured across multiple
tables, which can be joined together via a primary key or a foreign key. These unique identifiers demonstrate the different
relationships which exist between tables, and these relationships are usually illustrated through different types of data models.
Analysts use SQL queries to combine different data points and summarize business performance, allowing organizations to gain
insights, optimize workflows, and identify new opportunities.
For example:
 Relational databases are also typically associated with transactional databases, which execute commands, or transactions, collectively.
A popular example that is used to illustrate this is a bank transfer. A defined amount is withdrawn from one account, and then it is
deposited within another.

The total amount of money is withdrawn and deposited, and this transaction cannot occur in any kind of partial sense.

Transactions have specific properties,ACID properties are defined as:

Atomicity: All changes to data are performed as if they are a single operation. That is, all the changes are performed, or none of them
are.
Consistency: Data remains in a consistent state from state to finish, reinforcing data integrity.
Isolation: The intermediate state of a transaction is not visible to other transactions, and as a result, transactions that run concurrently
appear to be serialized.
Durability: After the successful completion of a transaction, changes to data persist and are not undone, even in the event of a system
failure.

Relational database vs. relational database management system

Conceptual and Physical Data Models

Conceptual Data Model: This Data Model defines WHAT the system contains. This model is typically created by Business stakeholders
and Data Architects. The purpose is to organize, scope and define business concepts and rules.
Logical Data Model: Defines HOW the system should be implemented regardless of the DBMS. This model is typically created by Data
Architects and Business Analysts. The purpose is to developed technical map of rules and data structures.
Physical Data Model: This Data Model describes HOW the system will be implemented using a specific DBMS system. This model is
typically created by DBA and developers. The purpose is actual implementation of the database.

Characteristics of a conceptual data model

 Offers Organisation-wide coverage of the business concepts.

 This type of Data Models are designed and developed for a business audience.
 The conceptual model is developed independently of hardware specifications like data storage capacity, location or software
specifications like DBMS vendor and technology. The focus is to represent data as a user will see it in the “real world.”

Characteristics of a Logical data model

Describes data needs for a single project but could integrate with other logical data models based on the scope of the project.
Designed and developed independently from the DBMS.
Data attributes will have datatypes with exact precisions and length

Characteristics of a physical data model:

 The physical data model describes data need for a single project or application though it maybe integrated with other physical data
models based on project scope.
 Data Model contains relationships between tables that which addresses cardinality and nullability of the relationships.
 Developed for a specific version of a DBMS, location, data storage or technology to be used in the project.
 Columns should have exact datatypes, lengths assigned and default values.
 Primary and Foreign keys, views, indexes, access profiles, and authorizations, etc. are defined.

Advantages and Disadvantages of Data Model:

Advantages of Data model:

 The main goal of a designing data model is to make certain that data objects offered by the functional team are represented
accurately.
 The data model should be detailed enough to be used for building the physical database.
 The information in the data model can be used for defining the relationship between tables, primary and foreign keys, and stored
procedures.
 Data Model helps business to communicate the within and across organizations.

Disadvantages of Data Model:

 To develop Data model one should know physical data stored characteristics.
 This is a navigational system produces complex application development, management.
 Even smaller change made in structure require modification in the entire application.
 There is no set data manipulation language in DBMS.

Entity and Attributes

Entity and attributes are crucial aspects of RDBMS's ER model. If we have a collection of laptops that all belong to the same firm, are
the same color, and have the exact specifications, we cannot distinguish them apart just on their looks.
And this is the reason why we are going to study Entity and Attributes because we must retrieve data from the database, and each of
them must have a distinct value that may be used to distinguish between two sets of data. As a result, we can refer to an item as an
entity when it becomes uniquely identifiable from the rest of the records in the database. So let's take a closer look at what an entity
is, as well as entity sets and types.

What is an Entity?
An entity is a distinct real-world thing, such as a person, a place, or a concept, that can be uniquely identified. It's an object that stands
out from the crowd.

Types of Entity

An entity can be of two types :

Tangible Entity: The term tangible entities refer to the physical entities that exist in the real world.
Example: a student, a keyboard, a bank locker, car, etc.

Intangible Entity: Entities with solely a cognitive existence and no physical existence.
Example: a Google Account, a bank account etc.

Example

In this particular example given below, we have a table named “Professor,” which contains multiple entities having attributes(Professor
ID, Professor Name, Professor City, Professor Salary) by which we can understand that every entity contains a unique Professor ID,
which is the key attribute of the table which helps to distinguish between the entities.

Types of Entity type

1. Strong Entity Type
2. Weak Entity Type
3. Strong Entity type

1. Strong Entity Type

A strong entity is one that is not reliant on other entities in the schema. A primary key is always present in a strong entity. A single
rectangle represents a strong entity. A single diamond represents the bond between two powerful creatures.
When various strong entities are united, they form a strong entity set.
How to represent Strong Entity type:

2. Weak Entity type

There is no key attribute for a weak entity type. It is unlikely to identify a weak entity type on its own. Its distinct identity is reliant on
the presence of another strong entity. A real-life example can help you understand this:
There can be children only if the parent exists. There can't be a separate existence for children. There can be a room only if the building
exits. There can't be a room that exists on its own.
How to represent Weak Entity type:
For example: Here, we can see that “Address” is a weak entity as the whole entity can not be identified on its own just by using address
entity type because it does not have any key attribute to identify the entity uniquely.

Entity Set
A group of entities with the same set of properties is referred to as an entity set. Each entity in an entity set has its own set of attribute
values that distinguishes it from the other entities in the table. The characteristics of no two entities in an entity set will have identical
values.
The Table in a database represents an entity set. The Student Table, which has numerous entities, is shown below. Even though both
kids have the name Jhoson, they are uniquely identified since they have separate roll numbers.

Attributes

In general, an attribute is a characteristic. In a database management system (DBMS), an attribute refers to a database component,
such as a table.
Example: In a general Student table we can consider attributes like Roll No, Mobile No, and Age where we have Roll No as a key or
primary attribute.

Types Of Attributes:
There are numerous types of attributes, including the following:
Simple Attribute & Composite Attribute
Single Valued Attribute & Multi-valued Attribute
Stored Attribute & Derived Attribute
Key Attribute & Non-key Attribute

Simple Attribute
Simple attributes are those that cannot be further divided into sub-attributes.
For example, A student's roll number of a student or the employee identification number. These attributes are usually assigned by an
organization and are used to identify an individual within that organization uniquely. Databases and other systems often use simple
attributes to track and manage information.

Composite Attributes
Composite attributes are made up of two or more simple attributes. For example, a person's address may be a composite attribute that
is made up of the person's street address, city, state, and zip code. Composite attributes can be used to create more complex data
models and can be helpful when trying to represent data in a concise way.

Single Valued Attributes

Single-valued attributes can only have one value. For example, a person's Social Security Number is a single-valued attribute. Social
Security Numbers are used to uniquely identify individuals in the United States and are, therefore, single-valued attributes.
Examples of single-valued attributes include employee numbers, customer numbers, and product codes. Single-valued attributes are
typically used to provide a unique identifier for an entity and are often used in databases.

Multivalued Attributes
Multivalued attributes can have more than one value. For example, a person may have multiple email addresses or phone numbers.
Multivalued attributes in DBMS are often used to store information about relationships between entities. For instance, an employee
entity might have a multivalued attribute called "dependents" that stores the names of the employee's dependents. Multivalued
attributes can also be used to represent hierarchical data.

Derived Attributes

Derived attributes are based on other attributes and are not stored directly in the database.
For example: Consider a database of employees. Each employee has a date of birth, and we might want to calculate their age.
However, age is a derived attribute because it can be determined from the date of birth. As such, it would not make sense to store it
directly in the database. Here is an example diagram of a derived attribute in DBMS:
Key Attributes
DBMS's key attributes are used to uniquely identify each row in a table. Usually, there is more than one key attribute in a table
(primary key and foreign key).
For example: In a table of employees, the employee ID would be the primary key, while the manager ID would be the foreign key.

Stored Attributes
In a DBMS, stored attributes are the data that remain constant and fixed for an entity instance. These values help in deriving the
derived attributes.
For example: consider a customer entity in a bank. The customer's name, age, and address would be stored attributes. The customer's
account balance (a derived attribute) could be calculated based on the transactions (another stored attribute) associated with the
customer.

Relationships
A relationship in DBMS is the way in which two or more data sets are linked, i.e., any association between two entity types is called a
relationship. So entity takes part in the relationship, and it is represented by a diamond shape.

for example

A teacher teaches students. Here, " teaches " is a relationship and this is the relationship between a Teacher entity and a Student
entity.
We have two entity types of 'Customer'(Customer_id, Name, City, Phone) and 'Account'(Account_no, Type, Balance). We store the
data of 'Customer' in one table and his accounts details in the 'Account' table. Now, to link these two tables we need to insert the
primary key 'Customer_id' of the 'Customer' table in the 'Account' table. This key acts as a foreign key for the 'Account' table and refers
to a column with the same name in the 'Customer' table. This is how a relationship between two tables is established.

Types of relationships
1. One-to-One Relationship
2. One-to-Many or Many-to-One Relationship
3. Many-to-Many Relationship

1. One-to-One Relationship
Such a relationship exists when each record of one table is related to only one record of the other table.

2. One-to-Many or Many-to-One Relationship

Such a relationship exists when each record of one table can be related to one or more than one record of the other table. This
relationship is the most common relationship found. A one-to-many relationship can also be said as a many-to-one relationship
depending upon the way we view it.
For example, If there are two entity type ‘Customer’ and ‘Account’ then each ‘Customer’ can have more than one ‘Account’ but each
‘Account’ is held by only one ‘Customer’. In this example, we can say that each Customer is associated with many Account. So, it is a
one-to-many relationship. But, if we see it the other way i.e many Account is associated with one Customer then we can say that it is a
many-to-one relationship.

3. Many-to-Many Relationship

Such a relationship exists when each record of the first table can be related to one or more than one record of the second table and a
single record of the second table can be related to one or more than one record of the first table. A many-to-many relationship can be
seen as a two one-to-many relationship which is linked by a 'linking table' or 'associate table'. The linking table links two tables by
having fields which are the primary key of the other two tables. We can understand this with the following example.
If there are two entity type ‘Customer’ and ‘Product’ then each customer can buy more than one product and a product can be bought
by many different customers.

Entity Relationship Modeling (ERDs)

What is an ER diagram?
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as people, objects or concepts relate to
each other within a system. ER Diagrams are most often used to design or debug relational databases in the fields of software
engineering, business information systems, education and research. Also known as ERDs or ER Models, they use a defined set of
symbols such as rectangles, diamonds, ovals and connecting lines to depict the interconnectedness of entities, relationships and their
attributes.

Database troubleshooting:
ER diagrams are used to analyze existing databases to find and resolve problems in logic or deployment. Drawing the diagram should
reveal where it’s going wrong.

Business information systems:

The diagrams are used to design or analyze relational databases used in business processes. Any business process that uses fielded
data involving entities, actions and interplay can potentially benefit from a relational database.
Business process re-engineering (BPR): ER diagrams help in analyzing databases used in business process re-engineering and in
modeling a new database setup.
Education: Databases are today’s method of storing relational information for educational purposes and later retrieval, so ER
Diagrams can be valuable in planning those data structures.
Research: Since so much research focuses on structured data, ER diagrams can play a key role in setting up useful databases to
analyze the data.

The components and features of an ER diagram

Entity : A definable thing such as a person, object, concept or event that can have data stored about it. Think of entities as nouns.
Examples: a customer, student, car or product. Typically shown as a rectangle.

Entity set: Same as an entity type, but defined at a particular point in time, such as students enrolled in a class on the first day. Other
examples: Customers who purchased last month, cars currently registered in Florida. A related term is instance, in which the specific
person or car would be an instance of the entity set.

Entity categories: Entities are categorized as strong, weak or associative. A strong entity can be defined solely by its own attributes,
while a weak entity cannot. An associative entity associates entities (or elements) within an entity set.

Entity keys:Refers to an attribute that uniquely defines an entity in an entity set. Entity keys can be super, candidate or primary. Super
key: A set of attributes (one or more) that together define an entity in an entity set.

Candidate key: A minimal super key, meaning it has the least possible number of attributes to still be a super key. An entity set may
have more than one candidate key. Primary key: A candidate key chosen by the database designer to uniquely identify the entity
set. Foreign key: Identifies the relationship between entities.

ERD symbols and notations

 Refining the Data Model

Tracking Data Changes

 Tracking Changes in SQL Server Databases.

 Tracking changes helps us know who and what changes were made thereby ensuring better accuracy in data that we preserve.
 Change tracking mechanisms can be developed by developers but that would involve sufficient development changes and
modifications to schema resulting in significant development efforts. It would also have significant performance overhead. Hence, SQL
Server provides different in-built tracking mechanisms like -
Change Tracking
Change Data Capture
System-versioned Temporal Tables.

Change Tracking
Change Tracking tracks what DML statements were used to perform the change. An important thing to note here is that the Change
Tracking utility does not track changes to historic data. In addition to tracking DML changes done to the tracked table, Change Tracking
also tracks the column that was changed. Change Tracking captures only the fact that rows are being changed but does not track the
content that was changed. Changes are tracked in a synchronous fashion. By ‘Synchronous’ we mean that Change Tracking reads
directly from the source tables.

Quick steps to enabling Change Tracking

1. Enable Change Tracking at a database level.
ALTER DATABASE Database_name SET CHANGE_TRACKING = ON (CHANGE_RETENTION = in_DAYS, AUTO_CLEANUP = ON/OFF)

2. Set up Change Tracking and specify the Change Retention period and Auto Cleanup.
ALTER TABLE Table_Name ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON)

Change Data Capture (CDC)

Change Data Capture tracks what DML statements were used to perform the change. In addition to this, this utility tracks changes to
historic data as well. Similar to Change Tracking, CDC tracks the column that was changed and any DML changes to the table that is
being tracked as part of the CDC utility. An important difference (with Change Tracking) to note is that ‘Change Data Capture’ captures
both the changes and the content that was changed in an asynchronous fashion. By ‘Asynchronous’ we mean that CDC does not read
directly from the source tables but uses the transaction log to get details of the changes.

System-versioned Temporal Tables

System-versioned temporal tables are user tables that help to keep track of the full history of changes in data tables. Tables that need
tobe tracked are altered to have a ‘SysStartTime’ and an ‘SysEndTime’ columns. Whenever a change is done to any row in the table,
the row is expired using the ‘SysEndTime’ and a new row is created which is denoted by a fresh ‘SysStartDate’. In addition to this, the
mechanism has a mirrored schema of the table being tracked.
Concluding Remarks — Deciding on a tracking mechanism
What is Database Normalization?
Normalization is a database design technique that reduces data redundancy and eliminates undesirable characteristics like Insertion,
Update and Deletion Anomalies. Normalization rules divides larger tables into smaller tables and links them using relationships. The
purpose of Normalisation in SQL is to eliminate redundant (repetitive) data and ensure data is stored logically.

Database Normal Forms

Here is a list of Normal Forms in SQL:

1NF (First Normal Form)
2NF (Second Normal Form)
3NF (Third Normal Form)
BCNF (Boyce-Codd Normal Form)
4NF (Fourth Normal Form)
5NF (Fifth Normal Form)
6NF (Sixth Normal Form)

DatabaseNormalization With Examples

Database Normalization Example can be easily understood with the help of a case study. Assume, a video library maintains a database
of movies rented out. Without any normalization in database, all information is stored in one table as shown below. Let’s understand
Normalization database with normalization example with solution:

Here you see Movies Rented column has multiple values. Now let’s move into 1st Normal Forms:
 1NF (First Normal Form) Rules
Each table cell should contain a single value.
Each record needs to be unique.
 1NF Example
What is Composite Key?

A composite key is a primary key composed of multiple columns used to identify a record uniquely. In our database, we have two
people with the same name Robert Phil, but they live in different places.

2NF (Second Normal Form) Rules

Rule 1- Be in 1NF
Rule 2- Single Column Primary Key that does not functionally dependant on any subset of candidate key relation
It is clear that we can’t move forward to make our simple database in 2nd Normalization form unless we partition the table above.

We have divided our 1NF table into two tables viz. Table 1 and Table2. Table 1 contains member information. Table 2 contains
information on movies rented.
We have introduced a new column called Membership_id which is the primary key for table 1. Records can be uniquely identified in
Table 1 using membership id
Database – Foreign Key
In Table 2, Membership ID is the Foreign Key

3NF (Third Normal Form) Rules

Rule 1- Be in 2NF
Rule 2- Has no transitive functional dependencies
To move our 2NF table into 3NF, we again need to again divide our table.
3NF Example
Below is a 3NF example in SQL database:

We have again divided our tables and created a new table which stores Salutations.
There are no transitive functional dependencies, and hence our table is in 3NF

What are transitive functional dependencies?

A transitive functional dependency is when changing a non-key column, might cause any of the other non-key columns to change
Consider the table 1. Changing the non-key column Full Name may change Salutation.

BCNF (Boyce-Codd Normal Form)

Even when a database is in 3rd Normal Form, still there would be anomalies resulted if it has more than one Candidate Key.
Sometimes is BCNF is also referred as 3.5 Normal Form.

4NF (Fourth Normal Form) Rules

If no database table instance contains two or more, independent and multivalued data describing the relevant entity, then it is in
4th Normal Form.
5NF (Fifth Normal Form) Rules
A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed into any number of smaller tables without loss of data.
6NF (Sixth Normal Form) Proposed
6th Normal Form is not standardized, yet however, it is being discussed by database experts for some time. Hopefully, we would have a
clear & standardized definition for 6th Normal Form in the near future…
That’s all to SQL Normalization!!!

What is data modeling and mapping?

Data modeling is the process of organizing and mapping data using simplified diagrams, symbols, and text to represent data
associations and flow. Engineers use these models to develop new software and to update legacy software. Data modeling also ensures
the consistency and quality of data.

Data vs. Information

• The words "data" and "information" are often used as if they are synonyms
−Nevertheless, they have different meanings
•Data:

Data is a collection of raw, unorganised facts and details like text, observations, figures, symbols and descriptions of things etc. In other
words, data does not carry any specific purpose and has no significance by itself. Moreover, data is measured in terms of bits and bytes
– which are basic units of information in the context of computer storage and processing.

−Raw or unprocessed material

•Information:

Information is processed, organised and structured data. It provides context for data and enables decision making. For example, a
single customer’s sale at a restaurant is data – this becomes information when the business is able to identify the most popular or least
popular dish.
−knowledge, intelligence, a particular piece of data with a special meaning or function
−Information is often the result of combining, comparing, analyzing or performing calculations on data

Data Information

Data is unorganised and unrefined facts Information comprises processed, organised data presented in a meaningful context

Data is an individual unit that contains raw materials which do not carry any specific meaning. Information is a group of data that collectively carries a logical meaning.

Data doesn’t depend on information. Information depends on data.

Raw data alone is insufficient for decision making Information is sufficient for decision making

An example of data is a student’s test score The average score of a class is the information derived from the given data.
History of the Database Timeline

• 1960s: Computers become cost effective for private companies, and storage capacity increases
• 1970-72: E. F. Codd proposes the relational model for databases, disconnecting the logical organization from the physical storage .
• 1976: P. Chen proposes the entity relationship model (ERM) for database design.
• Early 1980s: The first commercially-available relational database systems start to appear at the beginning of the 1980s with Oracle
Version 2
•Mid-1980s: SQL (structured query language) becomes "intergalactic standard"
• Early 1990s: An industry shakeout begins with fewer surviving companies. Oracle survives
• Mid-1990s: Kaboom! The usable Internet/World Wide Web (WWW) appears
−A mad scramble ensues to allow remote access to computer systems with legacy data
• Late 1990s: The large investment in Internet companies helps create a tools-market boom for Web/Internet/DB connectors
• Early 21st century: Solid growth of DB applications continues. Examples: commercial websites (yahoo.com, amazon.com,
google.com), government systems (Bureau of Citizenship and Immigration Services, Bureau of the Census), art museums, hospitals,
schools, etc

Database Development Process.

•Data modeling begins by researching the information requirements of a business

• Example: Here is a set of information requirements
−I manage the Human Resources Department for a large company
−We need to store data about each of our company’s employees
−We need to track each employee's first name, last name, job or position, hire date and salary
−For each employee on commission, we also need to track his/her potential commission
−Each employee is assigned a unique employee number

• Example: Here is a set of information requirements

−Our company is divided into departments
−Each employee is assigned to a department -- for example, accounting, sales, or development
−We need to know the department responsible for each employee and the department location
−Each department has a unique number
−Some of the employees are managers
−We need to know each employee's manager and all of the employees that are managed by each manager
•An entity relationship diagram should completely capture and accurately model the organization’s information needs and functions of
the business
• EXAMPLE
• The following entity relationship diagram represents the information requirements of the Human Resources Department
• Step two, the database design phase of the development process, translates the information modeled on the entity relationship
diagram to a table instance chart
• The table instance chart lists the design specifications of the information and has the following components:
−Table name
−Column names
−Keys: a primary key (PK) is the unique identifier for each row of data; a foreign key (FK) links data in one table to the data in a
second table by referring to the PK column in the second table
−Nulls: indicates if a column must contain a value (mandatory)
•Unique:
−indicates if the value contained in a column is unique within the table
•Data type:
−identifies the definition and format of the data stored in each Column
• Structured Query Language (SQL) commands are used to build the physical structure of the database

• SQL is also used to populate, access, and manipulate the data within the relational database

Major Transformations in Computing

History of Computer Systems
• 1970s
−The database software resided in the mainframe computer
−Almost all of the computer processing was done on these large mainframe computers
−Some of these computers were larger than your classroom!

• Smaller computers, or “dumb terminals,” were used to access the large mainframe and execute commands
• The terminals depended on the mainframe and displayed the results only after the processing was completed in the mainframe
• They were not capable of much processing on their Own
• 1980s
−As personal computers (PCs) became faster and widely available, processing moved from the mainframes to the desktop

−Because the PCs had their own software and were capable of doing some processing on their own, they came to be known as
“smart clients” or “workstations”
−Having the processing power within the client machine ushered in a wave of graphical user interface (GUI) applications
−Many of the common applications today (Word, Excel, PowerPoint) were born during this era

The Problem of Isolated, Nonintegrated Systems

•Having multiple applications on multiple client workstations created new problems

•In this example, different software on different systems requires integration
• This is usually troublesome and expensive

•If an upgrade is made to a software application, each and every server plus each and every client must be upgraded
• Think of a school district updating school grades on one system and attendance on another
•When a student graduates, all this information needs to be brought together
•Without an integrated system, this can be a painful process, especially if there are thousands of students who attend thousands of
days of school!
•Who will pull all that data together?
•In the grid-computing model, all of an organization’s computers in different locations can be utilized just like a pool of computing
resources
•Grid computing builds a software infrastructure that can run on a large number of networked servers

•A user makes a request for information or computation

from his workstation and that request is processed
somewhere in the grid, in the most efficient way
possible
•Grid computing treats computing as a utility, like the
electric company
• You don’t know where the generator is or how the electric grid is wired

• You just ask for electricity and you get it

•Grid Computing improves performance and reliability for Oracle’s system structures using database servers, application servers, and
client browsers

Cloud Computing:
• Cloud computing allows businesses to access software and hardware from a cloud provider
• These services are located remotely and delivered to users using web technologies
Entities, Instances, Attributes, and Identifiers

Purpose of Entities
• Knowing how to organize and classify data makes it possible to draw useful conclusions about seemingly random facts
•Our technology-rich world produces vast quantities of facts in need of structure and order
•It is important to learn about entities because they are the things about which we store data
• For example:
−A school needs to store data about (as a minimum): STUDENTs, TEACHERs, COURSEs, ROOMs, GRADEs

Purpose of Attributes
•It is important to learn about attributes because they provide more specific information about an entity
•Attributes help you distinguish between one instance and another by providing greater detail for the entity
• For example:
−In a restaurant, you need to list the individual items on a customer’s order so that you can calculate the bill
−When building several sales reports, you must be able to identify a specific report from the list of reports

Purpose Unique Identifiers

•What about unique identifiers?
−It is important to learn about unique identifiers because they distinguish one instance of an entity from another
−For example:
• In a classroom, you need to distinguish between one student and another
• When classifying your CD collection, you need to distinguish between one CD and another
• When listing transactions on a financial statement, you need to distinguish between one transaction and another

Entities and Instances

What is an Entity Relationship Model?
•An Entity Relationship Model:
−Is a list of all entities and attributes as well as all relationships between the entities that are of importance
−Provides background information such as entity descriptions, data types, and constraints
−Note: The model does not require a diagram, but the diagram is typically a very useful tool

Goals of ER Modeling
• There are four goals of ER modeling:
−Capture all required data
−Ensure that data appears only once
−Model no data that is derivable from other data already modeled
−Locate data in a predictable, logical place
•Imagine your school record—from your earliest days in school, data about you was captured
• Your absences, discipline history, classes taken, and grades earned are probably part of your record
• This data needs to be stored in a logical way, to allow accessing and updating records to be carried out easily and efficiently
• Following the goals of ER Modeling helps to achieve