IRIS is an Object Oriented DBMS under development at Hewlett Packard. It supports object model and normalized data.
A class is called a type and represents a collection of objects that share the same properties. A method is called a function and objects belonging to the same type share common functions. Objects respond only to their functions. Objects can be arranged in a hierarchy and inherit properties and functions
Object-Relational Model
Object-relational database management systems (ORDBMSs) add new object storage capabilities to the relational systems at the core of modern information systems. By encapsulating methods with data structures, an ORDBMS server can execute complex analytical and data manipulation operations to search and transform multimedia and other complex objects.
Relational Algebra
Relational Algebra is a procedural language which specifies how to get the required information and how to build a relation(set) from one or more other relations(sets). It specifies operations to be performed on existing relations(sets). The basic operations are the traditional set operations : UNION, DIFFERENCE, INTERSECTION and CARTESIAN PRODUCT. The first three operations, except Cartesian product, require that the operands(sets or relations or tables) be compatible(structurally same number, order and data-type of attributes) for the operation.
Consider the following two Operands(sets or relations or tables) which are Union compatible.
P Q
ID NAME ID NAME
101 Jones 103 Smith
103 Smith 104 Loly
104 Loly 106 Byron
107 Even 110 Drew
110 Drew
112 Smith
UNION operation
Hence R=P U(Union) Q
ID Name
101 Jones
103 Smith
104 Loly
107 Even
110 Drew
112 Smith
106 Byron
DIFFERENCE operation
Hence R=P-Q
ID Name
101 Jones
107 Even
112 Smith
R=Q-P
ID Name
106 Byron
INTERSECTION operation R=P Q
ID Name
103 Smith
104 Loly
110 Drew
CARTESIAN PRODUCT
P Q
ID NAME DEPTNAME
101 Jones Accounts
103 Smith Medical
104 Loly IT
107 Even
R=P X Q
ID NAME DEPTNAME
101 Jones Accounts
101 Jones Medical
101 Jones IT
103 Smith Accounts
103 Smith Medical
103 Smith IT
104 Loly Accounts
104 Loly Medical
104 Loly IT
107 Even Accounts
107 Even Medical
107 Even IT
Additional Relational Algebraic Operations
Besides the above 4 basic set operations, PROJECTION, SELECTION, JOIN and DIVISION.
Projection(Л)
The projection of a relation(table or set) is defined as a projection of all its tuples(rows) over some set of attributes, i.e., yields a vertical subset of the relation. The projection operation is used to either reduce the number of attributes in the relation under consideration or to reorder its attributes
PERSONAL Projection
ID NAME AGE ID AGE
1 A 23 1 23
2 B 56 2 56
3 C 34 3 34
4 D 87 4 87
5 E 25 5 27
The projection operation can also be used to reduce the cardinality of the resultant relation, that is, due to deletion of duplicate rows, if any.
Selection(σ)
The selection operation yields a horizontal subset of a given relation, that is, it selects only some tuples(rows) of a given relation under consideration. To have a tuple(row) included in the resultant relation, the specified selection conditions or predicates must be satisfied.
PERSONAL Selection(Age<=50)
ID NAME AGE ID NAME AGE
1 A 23 1 A 23
2 B 56 3 C 34
3 C 34 5 E 25
4 D 87
5 E 25
Join(∞)
It allows combining of two or more relations to form a single new relation. The tuples(rows) from the operand relations that participate in the join operation and contribute to the resultant relation are related. Thus, the join operation allows the processing of relationships existing between the operand relations.
DEPT EMP
Deptno Dname Empno Ename Age Deptno
10 Accounts 1 A 23 20
20 Medical 2 B 43 20
30 IT 3 C 65 30
4 D 42 10
5 E 45 30
6 F 62 10
Considering the above two operand relations(tables), suppose we want to respond to the query “Get the Empno of all employees whose department name is Accounts”.
This requires first computing the Cartesian product of the DEPT and EMP relations. Let us name this Cartesian product as TEMP. This is followed by selecting those tuples(rows) of TEMP where the attribute Dname has the value “Accounts” and the value of the attribute Deptno of DEPT relation is equal to the value of the attribute Deptno of EMP relation. The required result is obtained by projecting these tuples on the attribute Empno. The operations are shown below :
Cartesian Product : TEMP=(DEPT X EMP)
Projection :ЛEmpno(σ Dname=’Accounts’ ^ DEPT.deptno=EMP.deptno(TEMP))
Division(+)
Consider the following relation(table) P:
P
A B
a1 b1
a1 b2
a2 b1
a3 b1
a4 b2
a5 b1
a5 b2
Scenario 1
Now, if the relation Q is
Q
B
b1
b2
Hence, R= P ÷ Q
A
a1
a5
Scenario 2
Now, if the relation Q is
Q
B
b1
Hence, R= P ÷ Q
A
a1
a2
a3
a5
Scenario 3
Now, if the relation Q is
Q
B
b1
b2
b3
Hence, R= P ÷ Q
A
Empty
Scenario 4
Now, if the relation Q is
Q
B
Empty
Hence, R= P ÷ Q
A
a1
a2
a3
a4
a5
In scenario 1, the result of dividing P by Q is the relation R and it has two tuples. For each tuple in R, its product with the tuples of Q must be in P. In our scenario, (a1,b1), (a1,b2),(a5,b1) and (a5,b2) must all be tuples in P.
In scenario 2, the Cartesian product of Q and R gives a resulting relation which is again a subset of P.
In scenario 3, since there are no tuples in P with a value b3 for the attribute B(that is selectionB=b3(P)=0), we have an empty relation R, which has a cardinality of zero
In scenario 4, the relation Q is empty. It is unusual to allow division by an empty relation. The resultant relation is projection of P on the attributes in P-Q.
Consider Q as set of properties. Each tuple in P represents an object with some given property. The resultant relation R is a set of entities/tuples that posses all of the properties specified in Q. The two entities a1 and a5 posses all the properties, b1 and b2. The other entities/tuples in P, a2, a3 and a4 only posses one, not both, of the properties.
The Division operation is useful when a query involves the phrase “for all the objects/tuples having all the specified properties”
Relational calculus simply provides a definition of a relation in terms of one or more other relations. In other words, it says what data is required, but not how it is actually retrieved. Hence its is non-procedural, as it is a query system wherein queries are expressed as variables and formulas on these variables.
Relation Operators
In a relational operator is a construct that tests some kind of relation between two entities . These include numerical equality (e.g., 5=5) and inequality (e.g., 4≥3). In programming languages that include a distinct boolean type in their type system, like java, these operators return true or false, depending on whether the conditional relationship between the two entities holds or not. In other languages such as C, relational operators return the integers 0 or 1.
Relational Operator Symbol
EQ Equal to =
NE Not equal to <> or # or !=
GT Greater than >
GE Greater than or equal to >=
LT Less than <
LE Less than or equal to <=
An expression created using a relational operator forms what is known as a relational expression or a condition.
Database Design / Application Lifecycle
Before a database design is set into motion, planning is an essential stage. This is typically the responsibility of management within the organisation. Good planning will enable the design and implementation to be successfully completed with the desired results. A general definition of the desired system should also be drawn up at this stage. This would include information such as what the database application should be able to do, to what areas it will be applied, and who will be using it.
Three main factors that should be analysed in the planning are
What work will need to be done
The resources needed to complete the work
How much it will all cost
Requirements Analysis and Collection
Information can be gathered using various techniques. Some of these are listed below:
Interviewing individuals
Observation
Examining documents
Using questionnaires
Using expert knowledge and experience from other design work
Interviewing many individuals can be time consuming but can result in quality feedback which can be used in the system design. Using questionnaires is a quicker and easier way to gain feedback from relevant people. It is hard to ensure that the answers people give are accurate though. Looking at the current documents and paperwork in circulation can be useful in determining Database Design
The database design stage will result in a database model that will hopefully support the organization’s goals. The two design approaches that can be used are Bottom Up or Top Down. The Top Down approach starts with a very general overview of the system and details are added in an iterative manner. Bottom Up design involves getting all the details first then constructing the overall design from the smaller more detailed parts.
The aim of a database design should be to represent all relevant data and the relationships that exist between data items. The database model should also allow for all necessary transactions on the data to be possible.
The following stages follow the database design stage:
DBMS Selection
DBMS Selection
Application Design
Prototyping
Implementation
Data Conversion and Loading (if data from an existing system needs to be put into the new database)
Testing
Operational Maintenance (follows the installation of the system)
No comments:
Post a Comment