a. krasnopjorovs - web viewnosaukts savienojumu vai apvienība starp vienībām (merise...

A. KrasnopjorovsCASE rīks Power Designer 16.versija

RTU 2012.

SATURS

SATURS.......................................................................................................................................21. IEVĀDS................................................................................................................................32. UZDEVUMA NOSTĀDNE.................................................................................................43. DATU BĀZES APRAKSTS................................................................................................54. KONCEPTUĀLAS MODELIS (CDM).............................................................................7

3.1. Tabulu veidošana................................................................................................................73.2. Saišu veidošana................................................................................................................123.3. Modeļa pārbaude..............................................................................................................163.4. Citas notācijas..................................................................................................................17

5. LOĢISKĀIS DATU MODELIS (LDM).............................................................................205. FIZISKAIS DATU MODELIS...............................................................................................225. IMPACT ANALYSYS...........................................................................................................286 MODEĻU SALIDZINĀJUMS................................................................................................307. ATSKAITE.............................................................................................................................318. DATU BĀSE...........................................................................................................................329. SECINĀJUMI.........................................................................................................................5610. LITERATŪRAS SARAKSTS.......................................................................................57

1. DATU BĀZES APRAKSTSDatu bāzē tiek glabāti projekta dati, kurus izmanto programmatūras klienti,

kuri darbojas iPhone un Android aparātos. Klientu programmas savienojas ar sistēmas

serverī un pieprasa datus. Serveris, savu kārt, savienojas ar datu bāzes serveri un

pieprasa vajadzīgus datus. Kad dati tiek atrasti, tie tiek nodoti klientu programmām.

Datu bāze tiek glabāti dati par sistēmas lietotājiem, lietotājas atradīšanas

vietām, lietotājas ziņojumiem un lietotājas interesēm. Sakarā ar to var izvēlēties

sekojošas galvenās realitātes:

Realitātes nosaukums Apraksts

SNAQUST_USER Sistēmas lietotāji. Ir trīs klientu veidi:

iPhone

Android

Other platforms

MESSAGE Ziņojumi, kuri sistēmas lietotāji veido sistēmā.

Ir divi ziņojumu veidi:

ziņojums/jautājums

komentārs/atbilde

CATEGORY Ziņojumu kategorijas

INTEREST Lietotāju intereses.

LOCATION Lietotāju atrašanas vietā.

Tabula 1.

Zinot galvenās vienības ir iespējams sākt definēt vajadzīgas realitātes.

Realitātes Realitātes apraksts

ANDROID_USER Realitāte priekš Android lietotājas

specifiskajiem datiem.

CATEGORY Realitāte priekš ziņojumu kategorijas.

CITY Realitāte priekš pilsētām.

CONTRIES Realitāte priekš valstis informāciju.

CURRENT_GPS Tekošas lietotajā GPS koordinātes

INTEREST Lietotāja intereses

IOS_USER Realitāte priekš iPhone lietotājas


LOCATION Lietotāja atrašanas vieta.

MESSAGE Ziņojums

MSG_WITH_IMAGES Ziņojums ar attēlu

OTHER_USER Realitāte priekš Other lietotājas


QUESTION Jautājumi

REPLY_TO_QUESTION Atbildes uz jautājumiem

SNAQUEST_USER Sistēmas lietotāji

SOCIAL Lietotāju konti sociālajos tīklos

STREET Ielas

VISIT_HISTORY Lietotāju vizītes vēsture

Tabula 2.

2. KONCEPTUĀLAS MODELIS (CDM)

3.1. Tabulu veidošana

Lai sākt projektēt datu bāzi izmantojot Sybase PowerDesigner programmatūru

vispirms izveidot konceptuālo datu modeli (CDM). Veidojot datu bāzi, projektēšanas process

parasti sākas konceptuālā līmenī. CDM atspoguļo vispārīgo datubāzes struktūru, kas ir

neatkarīga no jebkuras programmatūras vai datu glabātuves veida. Konceptuālā līmenī,

nepieciešams apsvērt detaļas faktisko fizisko ieviešanas. CDM pārstāv vispārējo loģisko

struktūru datubāzē, kas ir neatkarīga no jebkuras programmatūras vai datu glabāšanas

struktūru. Konceptuāls modelis bieži satur datu objektus vēl nav ieviesta uz fiziskā datu bāzē.

Tas dod oficiālu pārstāvniecību vajadzīgos datus, lai palaistu uzņēmumu vai uzņēmējdarbību.

Apskatīsim šo procesu soļi pa solim. Atveriet Sybase PowerDesigner. Noklikšķiniet

File->New model…

Att. 1.

Atvērās modeļu izvēles logs, kur jāizvēlasConceptual Data Model un pēc tām

Conceptual Diagram (sk. att. 2). Pēc tām paradās tukšs konceptuālas modelis. Konceptuālais

modelis izmanto standart elementus, kuri tiek sasniedzami loga labajā pusē (sk. att. 3).

Att. 2

Att. 3

Objekts Tool AprakstsDomain -- Vērtību kopumu, par kuru dati ir derīgiData item -- Elementārais informāciju gabals

EntityPersona, vieta, lieta, vai jēdziens, kas ir īpašības, kas varētu interesēt uzņēmuma un par ko jūs vēlaties, lai saglabātu informāciju

Entity attribute -- Elementārais informācija gabals pievienots vienībai

Identifier -- Uzņēmums atribūts, vai juridiskās personas atribūtu kombinācija, kuru vērtības unikāli identificē katru rašanos uzņēmuma

Relationship Nosaukts savienojumu vai starp vienībām (vienību Attiecību (UR) modelēšanas metodoloģija) Saistība

Inheritance Īpašas attiecības, kas definē personu par īpašu gadījumu no plašākas vienībai

Association Nosaukts savienojumu vai apvienība starp vienībām (Merise modelēšana metodika)

Association link

Saite, kas savieno asociāciju, lai vienībai un par kuru jums noteikt cardinality uzņēmumam ir attiecībā pret citu

Tabula 3.

Lai izveidot tabulu jāizmanto Entity elementu no Conceptual Diagram sekcijas (sk.

att. 4). Kad Entity elements jau iz ievelēts, jā noklikšķināt uz tukša modeļa (loga centrālā

daļā), tad paradīsies jaunā tukša tabula (sk. att. 5.).

Att 4.

Att. 5.

Kad tabula ir izveidota ir iespējams sākt veidot tabulas atribūtus. Uzklikšķiniet divās

reizes uz jauni veidotas tabulas. Paradās Entity Properties logs (sk. att. 6.), šī forma ļauj

nosākt tabulas nosaukumu, atribūtus, identifikatorus un tml.

Att. 6

Lai izveidot atribūtus, jā pārslēgties uz Atribūtos nodaļu. Atribūtu ievade ir standarts

process, kurš ir līdzīgs citām sistēmām. Piemērām uz septītajā attēla ir paradīti atribūti priekš

tabulas SNAQUEST USER.

Att. 7

Kad visi atribūti tiek ievadīti ir iespējams izveidot tabulas identifikatoru. To var izdarīt Identifiers nodaļā (sk. att. 8).

Att. 8

Kad Identifikatora nodaļa ir atvērtā, tad ir iespējams izvelēties kādi tabulas atribūti būs iekļauti identifikatorā (sk. att. 9 un att. 10).

Att. 9

Ir iespējams izvēlēties vairākas atribūtus priekš

Att. 10.

Visas izveidotas tabulas ir pieejams gan uz modeļa, gan kreisajā pusē:

Att. 11.

Lai ērtāk izmantot atribūtus ir iespējams izveidot Domenus.

Att. 12.

Att. 13

Att. 14

Att. 15.

3.2. Saišu veidošana

Kad visas tabulas ir izveidotas, ir iespējams izveidot saites starp tabulām. Ir vairāki saišu veidi:

Saišu veids AprakstsMantojums / Inheritance Relationship Mantojuma attiecības raksturo attiecības

starp super-tipa vienību un tās paveidiem vienību. Kā, piemēram, ņemt lietu par grāmatu vienībā. Mēs varētu definēt divas apakšgrupas tipa vienībām, spēlēt un jauni, lai šī persona, kas pēc tam kļūst super-veida vienība.

Ideja ir tāda, ka super-veida uzņēmums būs galvenie parametri (atribūti), nosakot tās modelē objektu, tā kā katra apakš tips uzņēmumam būs aprakstīt īpašās ar tā īpašo apakšgrupas. Mūsu Piemēram, grāmata uzņēmums varētu saturēt vārdu, lappušu skaits un grāmatu autors. Spēlēt apakš tips uzņēmums varētu saturēt atribūtu apraksta aktu skaitu šajā spēlē un romāns apakšgrupas uzņēmums varētu saturēt atribūtu aprakstot vairākās sadaļās romānā.

Atkarīgais attiecības / Dependent Relationship

Atkarīgs Attiecības no uzņēmuma uz uzņēmuma B definē kā daļēji vai pilnībā identificē ar B identifikators. Kā, piemēram, pasūtījuma rindu varētu identificēt pēc tā pasūtījuma rindas numuru un kārtas numurs. Tas tiktu pārstāvēta ar atkarīgu attiecības starp pasūtījuma rindas vienībai un pasūtījuma vienību.

Asociatīvas struktūras / Associative Entities Asociatīvā Uzņēmums saņem nosaukumu un kodu attiecības.Lai mainītu attiecības stājas asociatīvā vienības:1) peles labo pogu noklikšķiniet attiecības līniju.Attiecību konteksta izvēlne2) Izvēlieties Mainīt uz Entity no konteksta izvēlni.Asociatīvā uzņēmums ar diviem attiecībām aizvieto attiecības.Asociatīvā Uzņēmums ņem vārdu sākotnējā attiecības.

Tabula 4

Ir trīs ziņojuma veidi: parastais ziņojums, jautājums un ziņojums ar attēlu. Lai paradītu šo konstrukciju es izvēlējis mantojuma saiti. Ir galvenā tabula MESSAGE un divās tabulas kuri manto visus MESSAGE atribūtus: QUESTION un MSG_WITH_IMAGES. Mantojuma attiecibu var apskatīt attēlā 12.

Att. 16.

Lai izveidot mantojuma attiecibu jāizmanto Inheritance objektu (sk. tabulu 3).Kad tabulas ir savienotas ar mantojuma saiti, tad to var nokonfigurēt. Lai to izdarīt ja divas reizes noklikšķinot uz izveidoto saiti (sk. att 12). Mantojuma konfigurēšanas forma sastāv no sekojošām daļām: General, Generation; Cildren; Notes; Rules.

Att. 17.

Att 18

Att. 19

Att. 20.

Tas ir vienīga mantojuma saite sistēmā, visas citas saites ir atkarīgas attiecības, piemērām ka starp SNAQUEST_USER un SOCIAL tabulām.

Att. 21.

Saites konfigurēšanas forma sastāv no sekojošām daļām: General, Cardinalities, Notes, Rules. Galvenā informācija par saiti ir pieejamā General daļā. Šeit var nodefinēt saistītas tabulas(lauki Entity 1 un Entity 2).

Att. 22.

Daļā Cardinalities ļauj nodefinēt saites veidu: ONE-ONE; ONE-MANY; MANY-ONE; MANY-MANY.

Att. 23.

Kad ir izveidotas visas saites tad tie ir redzami diagrammā un kreisā saraksta zem Entities (sk. att. 20).

Att. 24

3.3. Modeļa pārbaude

Kad konceptuālais modelis ir gatavs to jāpārbauda, lai atrisināt visās iespējamas

kļūdas. Lai pārbaudīt modeli jā izvēlās Tools->Check Model…

Att. 25

Att. 26

Gadījumā jā sistēma atradis kļūdas, tad to var izlabot vai manuāli, vai automātiski.

Automat. Manuālas izmaiņas tiek veidotas diagrammā. Automātiskas izmaiņas ir iespējams

izveidot uzklikšķinot ar labo pogu un izvēlēties Automatic Correction.

Att. 27

3.4. Citas notācijas

Kad konceptuālais modelis tiek pārbaudīts un nesatur kļūdas, tas ir iespējams izveidot

Loģisko modeli (LDM). Bet pirms to veidošanas ir iespējams izveidot konceptuālo modeli ar

citu notāciju, lai apskatīt modeļi „no cita leņķa”.

Eksistē vairākas notācijas, kurus lieto DKM atspoguļošanai: ER, Merise, E/R + Merise, IDEF1X. Lielākoties šīs notācijas atspoguļo vienu un to pašu būtību, bet atškiras ar simboliskajiem apzīmējumiem.

Diagramu ar jauno notāciju var izveidot Tools->Generate Conceptual Data Model (sk.

att 28), izvelēties Geneate new Conceptual Data Model un nospiest Configure Model Option..

pogu (sk. att 29) un izvēlēties vajadzīgo notāciju (sk. att 30)

Att 28

Att. 29

Att. 30

Sybase PowerDesigner piedāvā sekojošas notācijas:

Entity / Relationship struktūra / attiecības notācija savieno uzņēmumi ar saitēm, kas

pārstāv vienu no četriem attiecības starp tām. Šīs attiecības ir īpašības, kas attiecas uz

abām vienībām, kas iesaistītas attiecības

Merise - izmanto apvienības vietā attiecības, atšķiras no ER ar to, ka tajā saišu vietā

lieto tā sauktās asociācijas. Kad vairākas realitātes apvieno kāds notikums, ko nevar

īsti atspoguļot ar citu realitāti, viņas saista kopā ar asociāciju. Katrai realitātei

izveidojas asociācijas saite ar asociāciju, kurai ir jāizvēlās attiecības veids (1..*; *..*,

u.t.t.).

E/R + Merise- gan vienība / attiecību un Merise izmanto to pašu modeli

IDEF1X - datu modelēšana nošu attiecībām un organizācijām. Šajā apzīmējumā katrs

attiecību simbolu kopums apraksta kombināciju brīvās izvēles un cardinality no

uzņēmuma tai blakus

Barker - mantojumiem pārstāv novietojot bērnu vienības iekšpusē mātes uzņēmuma

simbolu, un attiecības ir sagatavots divās daļās, katra atspoguļo daudzveidību saistītās

uzņēmuma lomu.

Piemērām CDM Merise notācijā izskatas sekojoši:

Att. 31.

3.5. Izveidoto CDM apskatsDotajā darbā ietvaros tika izveidots sekojošais konceptuālais modelis. Modelis sastāv

no 17 tabulām un 17 saitēm starp tiem.

3. LOĢISKĀIS DATU MODELIS (LDM)Kad konceptuālais datu modelis ir izveidots un nesatur kļūdas, tas ir iespējams

izveidot Loģisko datu modeli (LDM). Loģiskais modelis ļauj veidot datubāzes struktūru un

veikt dažas datubāzes demoralizācijas rīcību. PowerDesignerī ir veidots loģiskais modelis,

izmantojot PDM ar <Logical Model> DBVS. Tas PDM ir fiziskā modeļa ar standarta

objektiem, un bez DBVS konkrētām fiziskām iespējām un ražošanas spējas.

Lai to uzģenerēt jāizvēlas Tools->Generate Logical Data model(att. 32) un nospiest

Configure Model Options (att. 33). Kad visi parametri tiek noteiki, var uzģenerēt LDM.

Dotajā darbā tiek izvēlēta Baker notācija priekš LDM (sk. att. 34).

Att. 32.

Att. 33.

Att. 34

Vienā no Baker notācijas atšķirībām ir mantojuma saites atspoguļojums.

Att. 35.

Dotajā darbā izveidotais LDM satur 20 tabulas un 23 saites starp tiem. Tas ir vairāk

nekā satur CDM modelis. To var paskaidrot ar to ko PowerDesigner konceptuālo modeļa

pārveidošanas laikā modificē tabulas (pievieno jaunas tehniskās atribūtus) un veido jaunas

tehniskās tabulas.

Zemāk ir izveidota tabula, kurā rada dažās atšķirības kuras ir CDM un LDM.

Konceptuālais modelis Loģiskais modelis

Kad Loģiskais modelis ir apskatīts, ir izlabotas visas neprecizitātes un ir novērstas

visas modeļa kļūdas tad ir iespējams izveidot Fizisko datu modeļi (PDM).

5. FIZISKAIS DATU MODELISFiziskais datu modelis atspoguļo visus objektus, kuri tiks fiziski izveidoti datu bāze.

Lai izveidot Fizisko datu modeli (Physical Data model PDM) jāizvēlas Tools->Physical Data

Model (att. 36) un nospiest Configure Model Options… (att 37).

Att. 36.

Att. 37

Kad modelis ir izveidots to jāpārbauda tādā pašā veida ka tika pārbaudītas

konceptuālais un loģiskais modelis. Fiziskais modelis sastāv no 20 tabulām un 25 saitēm starp

tiem.

Pēc tām, kad fiziskais modelis ir gatavs(att. 38) to jāielādē DBMS. Dotajā darbā ir

izmantots Oracle 11 XE versija.

Att. 38.

Vispirms ir nepieciešams izveidot savienojumu starp Sybase PowerDesigner un Oracle 11 XE. Lai to izdarīt ir nepieciešams izveidot ODBC savienojumu ar standartu MS Windows programmu odbcad32.exe. Kad ODBC draiveris ir izveidot tad jāizvēlas Database->Connect pogu (sk. att. 39) un tālāk ievadīt attiecīgus piekļuves datus (att. 40, att. 41).

Att. 39

Att. 40

Att. 41.

Ir iespējams pārbaudīt konekciju Database->Connection Informaton

Att. 42.

Kad Sybase PowerDesigner tiek pievienots pie DBMS Oracle 11XE var izveidot datu

bāzi. jāizvēlas Database->Generate Database…

Att. 43

Database Generation logā var izvēlēties gan Script generation gan Direct generation.

Atšķirība ir tāda, ka pirmajā gadījumā tiks izveidots fails ar SQL vaicājumiem, kurus var

izpildīt DBMS. Otrajā gadījumā tiks izveidota fiziskā dabu bāzē DBMS. Dotajā darbā

ietvaros tika izveidots SQL fails un fiziskā datu baze.

Att. 44.

Kad datu bāze tika izveidota, tad var izveidot testu datus un ielādēt tos datu bāzē lai

pārliecinātos ka SQL vaicājumi strādās pareizi. Lai ielādēt testu datus jāizvēlas Database-

>Generate Test Data…

Att. 45

Att 46.

Test Data Generation logā var izvēlēties gan Script generation gan Direct generation.

Atšķirība ir tāda, ka pirmajā gadījumā tiks izveidots fails ar SQL vaicājumiem, kurus var

izpildīt DBMS. Otrajā gadījumā testu dati tika ielādēti izveidotājā datu bāzē.

Dotajā darbā ietvaros tika izveidots SQL fails un testu dati tika ielādēti DBMS. Kad

testu dati ir ielādēti tad ir iespējams pārbaudīt ka darbojas SQL vaicājumi. Lai to izdarīt

jāizvēlas Database->Execute SQL…

Att. 47

Att. 48

Att. 49

5. IMPACT ANALYSYSSybase PowerDesingner piedāvā iespēju veiks iespaidās analīzi (impact analizi).

Tools->Impact and Lienage Analysis…

Att. 50

Att. 51

Dotajā darbā ietvaros nav iespējams izveidot šo funkciju iespējas.

6 MODEĻU SALIDZINĀJUMSJa ir izveidoti vairāki notācijas vienā līmenī, piemērām divi konceptuālie modeli, tad

ir iespējams salīdzināt tos.

Att. 52

Att. 53

Att. 54

7. ATSKAITESybase PowerDesingner piedāvā iespēju izveidot atskaiti par izveidot modeli, kurš

ērki atspoguļo izveidoto modeli.

Att. 55

Att. 56

Att. 57

8. DATU BĀSE/*==============================================================*/

/* DBMS name: ORACLE Version 11g */

/* Created on: 2012.12.12. 12:55:30 */

/*==============================================================*/

alter table ANDROID_USER

drop constraint "FK_ANDROID__USER CAN _SNAQUEST";

alter table CATEGORY

drop constraint "FK_CATEGORY_INTEREST _INTEREST";

alter table CITY

drop constraint "FK_CITY_COUNTY CO_COUNTRIE";

alter table CURREN_GPS

drop constraint "FK_CURREN_G_CURRENT U_SNAQUEST";

alter table LOCATION

drop constraint "FK_LOCATION_COUNTRY I_COUNTRIE";

alter table MSG_WITH_IMAGES

drop constraint FK_MSG_WITH_CREATE_SNAQUEST;

alter table OTHER_USER

drop constraint "FK_OTHER_US_USER CAN _SNAQUEST";

alter table QUESTION

drop constraint FK_QUESTION_CREATE2_SNAQUEST;

alter table REPLY_TO_QUESITON

drop constraint FK_REPLY_TO_RELATIONS_SNAQUEST;


drop constraint "FK_REPLY_TO_QUESTION _QUESTION";

alter table SOCIAL

drop constraint "FK_SOCIAL_USER HAS _SNAQUEST";

alter table VISIT_HISTORY

drop constraint "FK_VISIT_HI_USER'S HI_SNAQUEST";

alter table "categoris for location"

drop constraint FK_CATEGORI_CATEGORIS_CATEGORY;


drop constraint FK_CATEGORI_CATEGORIS_LOCATION;

alter table "cities contains streets"

drop constraint "FK_CITIES C_CITIES CO_STREET";


drop constraint "FK_CITIES C_CITIES CO_CITY";

alter table "each message has category"

drop constraint "FK_EACH MES_EACH MESS_MSG_WITH";


drop constraint "FK_EACH MES_EACH MESS_CATEGORY";


drop constraint "FK_EACH MES_EACH MESS_QUESTION";

alter table "message has location"

drop constraint "FK_MESSAGE _MESSAGE H_LOCATION";


drop constraint "FK_MESSAGE _MESSAGE H_MSG_WITH";


drop constraint "FK_MESSAGE _MESSAGE H_QUESTION";

alter table "user has interest"

drop constraint "FK_USER HAS_USER HAS _INTEREST";


drop constraint "FK_USER HAS_USER HAS _SNAQUEST";

drop index "user can use android_FK";

drop table ANDROID_USER cascade constraints;

drop index "interest has corresponding cat";

drop table CATEGORY cascade constraints;

drop index "county contains cities_FK";

drop table CITY cascade constraints;

drop table COUNTRIES cascade constraints;

drop index "current users location2_FK";

drop table CURREN_GPS cascade constraints;

drop table INTEREST cascade constraints;

drop index "country is detected by gps dat";

drop table LOCATION cascade constraints;

drop index "create_FK";

drop table MSG_WITH_IMAGES cascade constraints;

drop index "user can use another os_FK";

drop table OTHER_USER cascade constraints;

drop index "create2_FK";

drop table QUESTION cascade constraints;

drop index "Relationship_18_FK";

drop index "question could have answers_FK";

drop table REPLY_TO_QUESITON cascade constraints;

drop table SNAQUEST_USER cascade constraints;

drop index "User has social account_FK";

drop table SOCIAL cascade constraints;

drop table STREET cascade constraints;

drop index "user's history log_FK";

drop table VISIT_HISTORY cascade constraints;

drop index "categoris for location_FK";

drop index "categoris for location2_FK";

drop table "categoris for location" cascade constraints;

drop index "cities contains streets_FK";

drop index "cities contains streets2_FK";

drop table "cities contains streets" cascade constraints;

drop index "each message has category3_FK";

drop index "each message has category2_FK";

drop table "each message has category" cascade constraints;

drop index "message has location3_FK";

drop index "message has location_FK";

drop table "message has location" cascade constraints;

drop index "user has interest_FK";

drop index "user has interest2_FK";

drop table "user has interest" cascade constraints;

/*==============================================================*/

/* Table: ANDROID_USER */

/*==============================================================*/

create table ANDROID_USER

(

"android_version" VARCHAR2(10) not null,

"android_device" VARCHAR2(20) not null,

"android_user_id" INTEGER not null,

"user_id" INTEGER,

constraint PK_ANDROID_USER primary key ("android_user_id")

);

/*==============================================================*/

/* Index: "user can use android_FK" */

/*==============================================================*/

create index "user can use android_FK" on ANDROID_USER (

"user_id" ASC

);

/*==============================================================*/

/* Table: CATEGORY */

/*==============================================================*/

create table CATEGORY

(

"category" CLOB not null,

"category_id" INTEGER not null,

"interes_id" INTEGER,

constraint PK_CATEGORY primary key ("category_id")

);

/*==============================================================*/

/* Index: "interest has corresponding cat" */

/*==============================================================*/

create index "interest has corresponding cat" on CATEGORY (

"interes_id" ASC

);

/*==============================================================*/

/* Table: CITY */

/*==============================================================*/

create table CITY

(

"city_name" VARCHAR2(60) not null,

"city_id" INTEGER not null,

"country_id" INTEGER,

constraint PK_CITY primary key ("city_id")

);

/*==============================================================*/

/* Index: "county contains cities_FK" */

/*==============================================================*/

create index "county contains cities_FK" on CITY (

"country_id" ASC

);

/*==============================================================*/

/* Table: COUNTRIES */

/*==============================================================*/

create table COUNTRIES

(

"country_name" CLOB not null,

"gps_1" CLOB not null,




"country_id" INTEGER not null,

constraint PK_COUNTRIES primary key ("country_id")

);

/*==============================================================*/

/* Table: CURREN_GPS */

/*==============================================================*/

create table CURREN_GPS

(

"user_id" INTEGER,

"gps" CLOB not null,

"gps_id" INTEGER not null,

constraint AK_IDENTIFIER_1_CURREN_G unique ("gps_id")

);

/*==============================================================*/

/* Index: "current users location2_FK" */

/*==============================================================*/

create index "current users location2_FK" on CURREN_GPS (

"user_id" ASC

);

/*==============================================================*/

/* Table: INTEREST */

/*==============================================================*/

create table INTEREST

(

"category" CLOB not null,

"interes_id" INTEGER not null,

constraint PK_INTEREST primary key ("interes_id")

);

/*==============================================================*/

/* Table: LOCATION */

/*==============================================================*/

create table LOCATION

(

"gps" CLOB,

"location_id" INTEGER not null,

"country_id" INTEGER,

constraint PK_LOCATION primary key ("location_id")

);

/*==============================================================*/

/* Index: "country is detected by gps dat" */

/*==============================================================*/

create index "country is detected by gps dat" on LOCATION (

"country_id" ASC

);

/*==============================================================*/

/* Table: MSG_WITH_IMAGES */

/*==============================================================*/

create table MSG_WITH_IMAGES

(

"message_id" INTEGER not null,

"user_id" INTEGER not null,

"message_body" CLOB not null,

"time_start" DATE not null,

"time_updated" DATE not null,

"link_to_image" DATE not null,

"gps" CLOB,

"image" BLOB not null,

"image_id" INTEGER not null,

constraint PK_MSG_WITH_IMAGES primary key ("message_id", "image_id")

);

/*==============================================================*/

/* Index: "create_FK" */

/*==============================================================*/

create index "create_FK" on MSG_WITH_IMAGES (

"user_id" ASC

);

/*==============================================================*/

/* Table: OTHER_USER */

/*==============================================================*/

create table OTHER_USER

(

"user_id" INTEGER,

"apple_device" VARCHAR2(10) not null,

"os name" CLOB not null,

"os version" NUMBER(4,4) not null,

"other_device" VARCHAR2(20) not null,

"other_user_id" INTEGER not null,

constraint AK_OTHER_IDENTIFIER_1_OTHER_US unique ("other_user_id")

);

/*==============================================================*/

/* Index: "user can use another os_FK" */

/*==============================================================*/

create index "user can use another os_FK" on OTHER_USER (

"user_id" ASC

);

/*==============================================================*/

/* Table: QUESTION */

/*==============================================================*/

create table QUESTION

(


"question_id" INTEGER not null,


"message_body" CLOB not null,


"time_updated" DATE not null,

"link_to_image" DATE not null,

"gps" CLOB,

"solved" SMALLINT,

constraint PK_QUESTION primary key ("message_id", "question_id")

);

/*==============================================================*/

/* Index: "create2_FK" */

/*==============================================================*/

create index "create2_FK" on QUESTION (

"user_id" ASC

);

/*==============================================================*/

/* Table: REPLY_TO_QUESITON */

/*==============================================================*/

create table REPLY_TO_QUESITON

(

"ansv_id" CHAR(10) not null,

"message_id" INTEGER,

"question_id" INTEGER,

"user_id" INTEGER,

"ansv_body" CHAR(10),

constraint PK_REPLY_TO_QUESITON primary key ("ansv_id")

);

/*==============================================================*/

/* Index: "question could have answers_FK" */

/*==============================================================*/

create index "question could have answers_FK" on REPLY_TO_QUESITON (

"message_id" ASC,

"question_id" ASC

);

/*==============================================================*/

/* Index: "Relationship_18_FK" */

/*==============================================================*/

create index "Relationship_18_FK" on REPLY_TO_QUESITON (

"user_id" ASC

);

/*==============================================================*/

/* Table: SNAQUEST_USER */

/*==============================================================*/

create table SNAQUEST_USER

(


"user_name" CLOB not null,

"name" CLOB not null,

"surname" CLOB not null,

"password" VARCHAR2(16) not null,

"e-mail" VARCHAR2(100)

constraint "CKC_E-MAIL_SNAQUEST" check ("e-mail" is null or ("e-mail" >= '3' and "e-mail" in ('<Val0>'))),

"phone" CLOB,

"current_gps_id" INTEGER not null,

constraint PK_SNAQUEST_USER primary key ("user_id")

);

/*==============================================================*/

/* Table: SOCIAL */

/*==============================================================*/

create table SOCIAL

(


"facebook" VARCHAR2(100),

"twitter" VARCHAR2(100),

"instagram" VARCHAR2(100),

"google_plus" VARCHAR2(100),

"social_id" INTEGER not null,

constraint PK_SOCIAL primary key ("user_id", "social_id")

);

/*==============================================================*/

/* Index: "User has social account_FK" */

/*==============================================================*/

create index "User has social account_FK" on SOCIAL (

"user_id" ASC

);

/*==============================================================*/

/* Table: STREET */

/*==============================================================*/

create table STREET

(

"street_name" CLOB not null,

"street_id" INTEGER not null,

constraint PK_STREET primary key ("street_id")

);

/*==============================================================*/

/* Table: VISIT_HISTORY */

/*==============================================================*/

create table VISIT_HISTORY

(

"gps" CLOB not null,


"time_end" DATE not null,

"visit_id" INTEGER not null,

"user_id" INTEGER,

constraint PK_VISIT_HISTORY primary key ("visit_id")

);

/*==============================================================*/

/* Index: "user's history log_FK" */

/*==============================================================*/

create index "user's history log_FK" on VISIT_HISTORY (

"user_id" ASC

);

/*==============================================================*/

/* Table: "categoris for location" */

/*==============================================================*/

create table "categoris for location"

(



constraint "PK_CATEGORIS FOR LOCATION" primary key ("category_id", "location_id")

);

/*==============================================================*/

/* Index: "categoris for location2_FK" */

/*==============================================================*/

create index "categoris for location2_FK" on "categoris for location" (

"location_id" ASC

);

/*==============================================================*/

/* Index: "categoris for location_FK" */

/*==============================================================*/

create index "categoris for location_FK" on "categoris for location" (

"category_id" ASC

);

/*==============================================================*/

/* Table: "cities contains streets" */

/*==============================================================*/

create table "cities contains streets"

(

"street_id" INTEGER not null,

"city_id" INTEGER not null,

constraint "PK_CITIES CONTAINS STREETS" primary key ("street_id", "city_id")

);

/*==============================================================*/

/* Index: "cities contains streets2_FK" */

/*==============================================================*/

create index "cities contains streets2_FK" on "cities contains streets" (

"city_id" ASC

);

/*==============================================================*/

/* Index: "cities contains streets_FK" */

/*==============================================================*/

create index "cities contains streets_FK" on "cities contains streets" (

"street_id" ASC

);

/*==============================================================*/

/* Table: "each message has category" */

/*==============================================================*/

create table "each message has category"

(



constraint "PK_EACH MESSAGE HAS CATEGORY" primary key ("message_id", "category_id")

);

/*==============================================================*/

/* Index: "each message has category2_FK" */

/*==============================================================*/

create index "each message has category2_FK" on "each message has category" (

"category_id" ASC

);

/*==============================================================*/

/* Index: "each message has category3_FK" */

/*==============================================================*/

create index "each message has category3_FK" on "each message has category" (

"message_id" ASC

);

/*==============================================================*/

/* Table: "message has location" */

/*==============================================================*/

create table "message has location"

(



constraint "PK_MESSAGE HAS LOCATION" primary key ("location_id", "message_id")

);

/*==============================================================*/

/* Index: "message has location_FK" */

/*==============================================================*/

create index "message has location_FK" on "message has location" (

"location_id" ASC

);

/*==============================================================*/

/* Index: "message has location3_FK" */

/*==============================================================*/

create index "message has location3_FK" on "message has location" (

"message_id" ASC

);

/*==============================================================*/

/* Table: "user has interest" */

/*==============================================================*/

create table "user has interest"

(

"interes_id" INTEGER not null,


constraint "PK_USER HAS INTEREST" primary key ("interes_id", "user_id")

);

/*==============================================================*/

/* Index: "user has interest2_FK" */

/*==============================================================*/

create index "user has interest2_FK" on "user has interest" (

"user_id" ASC

);

/*==============================================================*/

/* Index: "user has interest_FK" */

/*==============================================================*/

create index "user has interest_FK" on "user has interest" (

"interes_id" ASC

);

alter table ANDROID_USER

add constraint "FK_ANDROID__USER CAN _SNAQUEST" foreign key ("user_id")

references SNAQUEST_USER ("user_id");

alter table CATEGORY

add constraint "FK_CATEGORY_INTEREST _INTEREST" foreign key ("interes_id")

references INTEREST ("interes_id");

alter table CITY

add constraint "FK_CITY_COUNTY CO_COUNTRIE" foreign key ("country_id")

references COUNTRIES ("country_id");

alter table CURREN_GPS

add constraint "FK_CURREN_G_CURRENT U_SNAQUEST" foreign key ("user_id")


alter table LOCATION

add constraint "FK_LOCATION_COUNTRY I_COUNTRIE" foreign key ("country_id")

references COUNTRIES ("country_id");

alter table MSG_WITH_IMAGES

add constraint FK_MSG_WITH_CREATE_SNAQUEST foreign key ("user_id")


alter table OTHER_USER

add constraint "FK_OTHER_US_USER CAN _SNAQUEST" foreign key ("user_id")


alter table QUESTION

add constraint FK_QUESTION_CREATE2_SNAQUEST foreign key ("user_id")



add constraint FK_REPLY_TO_RELATIONS_SNAQUEST foreign key ("user_id")



add constraint "FK_REPLY_TO_QUESTION _QUESTION" foreign key ("message_id", "question_id")

references QUESTION ("message_id", "question_id");

alter table SOCIAL

add constraint "FK_SOCIAL_USER HAS _SNAQUEST" foreign key ("user_id")


alter table VISIT_HISTORY

add constraint "FK_VISIT_HI_USER'S HI_SNAQUEST" foreign key ("user_id")



add constraint FK_CATEGORI_CATEGORIS_CATEGORY foreign key ("category_id")

references CATEGORY ("category_id");


add constraint FK_CATEGORI_CATEGORIS_LOCATION foreign key ("location_id")

references LOCATION ("location_id");


add constraint "FK_CITIES C_CITIES CO_STREET" foreign key ("street_id")

references STREET ("street_id");


add constraint "FK_CITIES C_CITIES CO_CITY" foreign key ("city_id")

references CITY ("city_id");


add constraint "FK_EACH MES_EACH MESS_MSG_WITH" foreign key ("message_id")

references MSG_WITH_IMAGES ("message_id");


add constraint "FK_EACH MES_EACH MESS_CATEGORY" foreign key ("category_id")

references CATEGORY ("category_id");


add constraint "FK_EACH MES_EACH MESS_QUESTION" foreign key ("message_id")

references QUESTION ("message_id");


add constraint "FK_MESSAGE _MESSAGE H_LOCATION" foreign key ("location_id")

references LOCATION ("location_id");


add constraint "FK_MESSAGE _MESSAGE H_MSG_WITH" foreign key ("message_id")

references MSG_WITH_IMAGES ("message_id");


add constraint "FK_MESSAGE _MESSAGE H_QUESTION" foreign key ("message_id")

references QUESTION ("message_id");


add constraint "FK_USER HAS_USER HAS _INTEREST" foreign key ("interes_id")

references INTEREST ("interes_id");


add constraint "FK_USER HAS_USER HAS _SNAQUEST" foreign key ("user_id")


9. SECINĀJUMISybase PowerDesigner ir lieliska programma, kura ļauj efektīvi izveidot un pārbaudīt

datu bāzi. Konceptuālais modelis tika izveidots projekta dizainā stadijā. Tas ir ērti, jo ne

vienmēr ir zināms kāda tehnoloģija būs izmantota. Pēc tehnoloģijas izvēles, tad ir ērti un ātri

izveidot fizisko datu modeli. Visas transformācijas jau notiek automātiski, bet specialistam

vienmēr pastāv iespēja izlabot kļūdas vai veiks nepieciešamas izmaiņas. PowerDesigner

piedāvā vairākas notācijas un datu bāzes projektētajam ir iespējams izmantot piemērotāku.

Man izdevās izveidot datu bāzi kuru es plānoju izveidot, bet joprojām man ir sajūa ko

šo uzdevumu var risināt efektīvāk. Diemžēl laikā trūkumā dēļ nebija iespējas dziļāk izpētīt

PoweDesigner riku. Darbā gaitā izvirzījāsdažas tehniskās problēmas ar savienojumu ar Oracle

DBMS, bet visas tika atrisinātas. Darba ietvaros tika izstrādāta efektīva datu bāze. Viena no

problēmām bija saistīta ar BLOB datu tipu. Izradījās, ka PowerDesigner testu datus

ģenerēšanas procesa nespēji aizpildīt laukus ar BLOB tipu.

Dotajā darbā netika apskatīta PowerDesigner iespēja būt pār komandas riku un par

reversa Engineering riku.

10.LITERATŪRAS SARAKSTS1. Sybase PowerDesigner 16.1 tutorial.

a. krasnopjorovs - web viewnosaukts savienojumu vai apvienība starp vienībām (merise...

Documents