Aggregation is a tightly coupled (cieši saistīta) form of association. The main difference between aggregation and association is the underlying semantic strength. While an aggregation forms a method of organization that exactly maps human thinking, an association is a mere mapping (skaidrs attēlojums) between objects in an application. Aggregation is a composition or “part-of” relationship, in which a composite object (whole) consists of other component objects (parts).

In an aggregation relationship, in which one whole can have many parts associated with it through a part-of relationship, the entire part-of relationship is viewed as one composition, not several association relationships.

There are four types of composition:1) sharable (exclusive) dependent (existence-dependent);2) sharable independent (existence-independent);3) nonsharable (nonexclusive) dependent;4) nonsharable independent.

Existence-dependent and existence-independent compositions are two aggregation types in which the dependencies between the whole object and its part objects are significant.IN UML: Composition = exclusive dependentA heterogeneous composition since one whole object may consist of several different types of part objects. In contrast, homogeneous composition implies that one whole object consists of part objects of the same type.The composition hierarchy may span an arbitrary number of levels. If one gets a composite or aggregated object design that has component objects that are themselves composite or aggregated objects, then one gets a two-level aggregation or composition hierarchy. This hierarchy could be repeated to several levels of composition or aggregation. Because of the arbitrary number of the part-of relationships between the objects, the objects involved in the composition are also known as complex objects.

1

Mantošanas (inheritance) tipiObjekts var iegūt (mantot) cita objekta īpašības (datus, metodes).

1. Vienkāršā (single) mantošana.

2. Saliktā jeb daudzējādā (multiple) mantošana.

3. Saliktā ceļa (multipath) mantošana.

Virsklase, bāzes klase

Pakārtotā klase

Virsklase, bāzes klase

Virsklase, bāzes klase

Pakārtotā klase

Virsklase, bāzes klase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase, bāzes klase

2

4. Daudzlīmeņu (multilevel) mantošana.

4. Hierarhiskā (hierarhical) mantošana.

5. Hibrīdtipa (hybrid = single + multiple)) mantošana.

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Pakārtotā klase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

Virsklase

Pakārtotā klase

3

Bāzes klase

V

Apakšklase Apakšklase

Bāzes klase

S

Apakšklase Apakšklase

Bāzes klase

A

Apakšklase Apakšklase

Bāzes klase

K

Apakšklase Apakšklase

Mantošanas interpretējumiVispārinājums ("is a"). Apakšklase manto bāzes klases atribūtus un saites.

Specializācija ("is a"). Bāzes klasei pievienojasapakšklases atribūti un saites.

Agregācija ("part of"). Daļas un veselais eksistē patstāvīgi. Viena daļa var attiekties uz vairākiem veseliem.

Kompozīcija ("part of"). Daļas neeksistē bez veselā.

4

Absolūtā specializācija (total specialization) – katram bāzes klases eksemplāram ir vismaz viens apakšklases eksemplārs.

Daļējā specializācija (partial specialization) – ne katram bāzes klases eksemplāram ir atbilstošs pakārtototās klases eksemplārs.

Sadalījums (disjoint) – katram bāzes klases eksemplāram var būt ne vairāk kā viens atbilstošais elements no apakšklasēm.

Grāmata

AS

Dzejoļu grāmata

Romāns Cits tips

Dzīvnieks

SA

Lauva Zirgs Suns

Grāmata

DS

Dzejoļu grāmata Romāns

1

5

Darbinieks

StrādnieksVadītājs

Gadījuma strādnieks

Darbinieks

StrādnieksVadītājs

Savstarpēji izslēdzošā (mutual – exclusion) mantošanā apakšklašu objekti nevar vienlaicīgi piederēt pie vairākām bāzes klasēm, turklāt galvenās klases objekts var nepiederēt nevienai no apakšklasēm.

Pārklāšanās (overlapping) – katram bāzes klases eksemplāram var atbilst vairāku apakšklašu eksemplāri.

Nodalīšanas (partition) mantošana ir apvienojošās un savstarpēji izslēdzošās mantošanas apvienojums:1) apakšklašu grupas veido savstarpēji izslēdzošas grupas.

Upe

P

Liela Maza Strauja

N

6

Apvienojošā (union) mantošanā katrs galvenās klases objekts obligāti pieder

kādai no apakšklasēm, turklāt, galvenās klases objekts var piederētvairākām

apakšklasēm vienlaicīgi. Attēlā ir parādīts apvienojošās mantošanas piemērs,

kurā katrs augu kaitēklis pieder vismaz pie vienas no apakšklasēm – pie

bumbieru kaitēkļiem vai ķiršu kaitēkļiem, turklāt kaitēklis var vienlaicīgi būt

bumbieru kaitēklis un ķiršu kaitēklis.

7

Daudzkārtīga mantošana (multiple inheritance) – apakšklases eksemplāri ir saistīti ar vairākām bāzes klasēm.

Apvienojums (union) - apakšklase ir saistīta ar vairākām bāzes klasēm un apakšklases eksemplārs vienlaikus manto atribūtus un saites tikai no vienas bāzes klases eksemplāra.

Pirkums (purchase)

AP

Produkts Pakalpojums

Dzīvnieks Cilvēks

Nāra

Bāzes klases

Apakšklase

DM

Apakšklase

Bāzes klases

XOR

8

An inheritance relationship is generally known as a generalization or specialization relationship, in which the definition of a class can be based on other existing classes. Inheritance is a key feature of the object oriented paradigm.Rather than being considered as an extension, inheritance can be viewed as a restriction on the superclass by hiding previously exported features of the superclass.

9

Persona

PasniedzējsStudents

Relāciju – objektu datu bāzes (RODB) datu glabāšanas struktūru mantošanas saites

Apvienojošā mantošanaApvienojošā (union) mantošanā:1) katrs galvenās klases objekts ir obligāti saistīts ar kādas apakšklases objektu;2) galvenās klases objekts var būt saistīts ar vairākiem apakšklases objektiem (apakšklases objekts var būt arī citas apakšklases objekts (students var būt arī pasniedzējs)).

If we use the Oracle version, which supports inheritance using the “under” keyword, we can create Student and Staff subclasses under the superclass Person. Note that for union inheritance, we need to create one table each for the superclass and all the subclasses.Using the “under” keyword, normally we do not need to create separate tables for the subclasses because the table created for the superclass can also be used to store the instances of the subclasses. However, in this union type of inheritance, we need to allow a particular person to be both a student as well as a staff. If we are to store all instances into one superclass table, we will not be able to store the two records together as they will violate the primary-key constraints (i.e., two records with the same ID). Therefore, we need to create a separate table for each of the subclasses to allow the same person’s record to appear in both the Student as well as Staff tables. We also need to create a table for Person to store persons who are neither staff members nor students.

CREATE OR REPLACE TYPE Person_T AS OBJECT (id VARCHAR2(10),name VARCHAR2(20),address VARCHAR2(35)) NOT FINAL; CREATE TABLE Person OF Person_T (id NOT NULL, PRIMARY KEY (id)); CREATE OR REPLACE TYPE Student_T UNDER Person_T (course VARCHAR2(10), year VARCHAR2(4));

CREATE TABLE Student OF Student_T (id NOT NULL, PRIMARY KEY (id));

CREATE OR REPLACE TYPE Staff_T UNDER Person_T (department VARCHAR2(10), room_no VARCHAR2(4));

CREATE TABLE Staff OF Staff_T (id NOT NULL, PRIMARY KEY (id));

10

Darbinieks

StrādnieksVadītājs

Savstarpēji izslēdzošā mantošanaSavstarpēji izslēdzošā (mutual – exclusion) mantošanā:1) apakšklašu objekti nav saistīti (darbinieks ir tikai vai nu vadītājs vai strādnieks, ne abi divi).2) galvenās klases objekts var būt nesaistīts ar kādu apakšklases objektu.

Using the newer Oracle version, we can create Manager and Worker subclasses under the superclass Employee. Notice that in this type of inheritance, we create only one table for the superclass. We do not need subclass tables because an object can be a member of only one subclass. These subclasses are instantiations of the superclass. Also notice that although the table is created from the superclass table, Oracle maintains the integrity constraint between the subclass and the superclass table. We cannot delete the subclass while the superclass table still exists. In this case, an employee can only be a manager, a worker, or neither. If an employee is neither a manager nor a worker, he or she is only an object of the superclass, Employee. If an employee is a manager, for example, he or she will be an object of the subclass Manager. Thus, the employee will have all of the attributes of the Manager type and all other attributes that are inherited from the Employee type. However, all of the subclass tables can be kept in the superclass table.CREATE OR REPLACE TYPE Employee_T AS OBJECT (id VARCHAR2(10), name VARCHAR2(20), address VARCHAR2(35), emp_type VARCHAR2(8)) NOT FINAL;

CREATE TABLE Employee OF Employee_T (id NOT NULL,emp_type CHECK (emp_type in (‘Manager’, ‘Worker’, ‘NULL’)), PRIMARY KEY (id));

CREATE OR REPLACE TYPE Manager_T UNDER Employee_T (annual_salary NUMBER);

CREATE OR REPLACE TYPE Worker_T UNDER Employee_T (weekly_wage NUMBER);

11

Gadījuma strādnieks

Darbinieks

StrādnieksVadītājs

Nodalīšanas mantošanaNodalīšanas (partition) mantošana ir apvienojošās un savstarpēji izslēdzošās mantošanas apvienojums:1) apakšklašu grupas veido savstarpēji izslēdzošas grupas;2)

We use the example of an employee again, but here a new class, Casual, is added, and it is assumed that each member of the Employee class must belong to one and only one of the classes Manager, Worker, and Casual. For example, an employee cannot be both a manager and a casual. Similar to the other types of inheritance, the best way to map the partition type of inheritance into tables is to have one table for each superclass and one for each subclass. Like the mutual-exclusion type, a new attribute emp_type is added to the superclass table. The difference is that this new attribute has a constraint, which is “not null.” This will ensure that each superclass object belongs to a particular subclass type. It also ensures that no superclass object belongs to more than one subclass. Notice that the attribute emp_type is also needed in the Employee table with the “not null” constraint. The newer Oracle version can also accommodate this inheritance type. It is very similar to the implementation in the mutual-exclusion type. The only difference is the constraint of emp_type in the Employee table.

CREATE OR REPLACE TYPE Employee_T AS OBJECT (id VARCHAR2(10), name VARCHAR2(20), address VARCHAR2(35), emp_type VARCHAR2(8)) NOT FINAL; CREATE TABLE Employee OF Employee_T (id NOT NULL, emp_type NOT NULL CHECK (emp_type in (‘Manager’, ‘Worker’, ‘Casual’)), PRIMARY KEY (id));

CREATE TYPE Manager_T same as in mutual exclusive inheritance

CREATE TYPE Worker_T same as in mutual exclusive inheritance

CREATE OR REPLACE TYPE Casual_T UNDER Employee_T (hourly_rate NUMBER);

12

Privātskolotājs

Persona

PasniedzējsStudents

Daudzkārtējā (multiple) mantošanaDaudzkārtējā (multiple) matošana:1) vienas apakšklases objektus manto vairākas galvenās klases.

A Tutor class can be said to be inheriting from overlapping classes because basically a tutor can be a student who is also a staff member. The best way to handle this inheritance from overlapping classes is to use one table for each superclass and one table for the subclass. Figure gives an example of a multiple inheritance implementation. A Tutor class can be said to be inheriting from overlapping classes Student and Staff.At the time of this writing, the newer Oracle does not support multiple inheritance using the “under” keyword. This keyword is applicable only to the single inheritance type. However, this multiple inheritance concept is often simulated using other existing techniques. For example, we can use the “under” keyword to implement one inherited parent, and use an association type to link to the other parent. The drawback of using this technique is that only the parent type implemented using “under” can be inherited, and therefore we have to be careful when choosing which parent to inherit and which one to associate.

CREATE TABLE Person (id VARCHAR2(10) NOT NULL, name VARCHAR2(20), address VARCHAR2(35), PRIMARY KEY (id));

CREATE TABLE Student (id VARCHAR2(10) NOT NULL, course VARCHAR2(10), year VARCHAR2(4), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE); CREATE TABLE Staff (id VARCHAR2(10) NOT NULL, department VARCHAR2(10), room_no VARCHAR2(4), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE);

CREATE TABLE Tutor (id VARCHAR2(10) NOT NULL, no_hours NUMBER, rate NUMBER, PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE);

13

Relāciju – objektu datu bāzes (RODB) datu glabāšanas struktūru agregācijas un kompozīcijas saites1. Agregācijas saiteAgregācijas saite norāda, ka objekts ir salikts (complex object). Tātad eksistē veselais un daļas. Agregācijas saite norāda sekojošu attiecību starp vesalo objektu un daļu objektiem:1) daļas objekts pieder tikai vienam veselajam objektam (exclusive) vai vairākiem (nonexclusive);2) ja tiek likvidēts veselais objekts, daļas objekti paliek (neatkarīgā esamība (existence independent)).

EER diagramma

RORB datu glabāšanas struktūra (exclusive variants)

objektu saite

1 : 1

RORB datu glabāšanas struktūra (nonexclusive variants)

objektu saite

N : 1

FakultāteAtr1Atr2Atr3

PasniedzējsAtr4Atr5Atr6

Tabula ar rindas tipa objektiem ar atsaucēm (Ref) Objekts (OID, Atr4, Atr5, Atr6, Ref)

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3)

Tabula ar kolekciju. Kolekcijas veido atsauces Ref. Kolonas: Atr4, Atr5, Atr6, AtsaucesKolonu Atsauces veido objektu kolekcijas ar atsaucēm.

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3)

14

2. Kompozīcija (salikti objekti (complex objects))Kompozīcijas saite norāda sekojošu attiecību starp vesalo objektu (saliktu objektu) un daļu objektiem:1) daļas objekts pieder tikai vienam veselajam objektam vai vairākiem (exclusive, nonexclusive);2) ja tiek likvidēts veselais objekts, tiek likvidēti arī daļas objekti (atkarīgā esamība (existence dependent)).

EER diagramma

RORB datu glabāšanas struktūra (exclusive variants)

RORB datu glabāšanas struktūra (nonexclusive variants)

objektu saite

N : 1

A heterogeneous composition since one whole object may consist of several different types of part objects.

A homogeneous composition implies that one whole object consists of part objects of the same type.

DzīviklisAtr1Atr2Atr3

IstabaAtr4Atr5Atr6

Tabula ar objektu kolekcijuKolonas: Atr1, Atr2, Atr3, ISTABAKolona ISTABA satur objekta (Atr4, Atr5, Atr6) objekta kolekcijas

Tabula ar rindas tipa objektiemObjekts (OID, Atr1, Atr2, Atr3).Trigeris daļveida objektu dzēšanai, ja tiek dzēsts veselais objekts.

Tabula ar kolekciju. Kolekcijas veido atsauces Ref. Kolonas: Atr4, Atr5, Atr6, AtsaucesKolonu Atsauces veido objektu kolekcijas ar atsaucēm.

15

Ģeometriskā objekta

pamatdati

Punkta koordinātes Triplets (grafiskā

primitīva apraksts)

Salikta grafiskā objekta apraksts

Salikta grafiskā objekta

koordinātes

Grafiskā primitīva objekta

koordinātes

Grafiskās datu bāzes datu glabāšanas struktūra izmantojot SDO_GEOMETRY objekta tipuĢeometrijas objektu glabāšanas RODB tabula (tabula ar objektu kolonu)

Objekta tipa SDO_GEOMETRY datu EER diagramma

16

SDO_GEMETRYETRY

SDO_GEMETRYETRY

SDO_GTYPE

SDO_SRID

SDO_POINT

SDO_ELEM_INFO--------------------------------------SDO_STARTING_OFFSET

SDO_ETYPESDO_INTERPRETATION

SDO_ORDINATES----------------------X1,Y1,X2,Y2, ...

Atr Atr AtrAtr

Atr

Atr

Atr Atr AtrAtr Atr Atr

Atr Atr Atr

Objektu tipa SDO_GEOMERTY struktūra

AtrAtr

17