Ordliste over udtryk og definitioner

Der er nogle grundlæggende koncepter, der bruges i og henvises til i hele DDB -platformen og dokumentationen.

Miljøer

DDB har tre forskellige miljøer med forskellige formål.

Miljø	URL	Beskrivelse	Hvornår skal man bruge
Udvikling	dev.ddb.arup.com (opens new window)	Det første er vores DDB -udviklingswebsted, der primært bruges af udviklingsholdet til at teste nye funktioner. Denne server udslettes regelmæssigt uden advarsel, så gem ikke nogen live -projektdata der. DDB -teamet er ikke ansvarligt for datatab, der er gemt i dette miljø.	Brug dette miljø, når du udforsker din datamodel. Det er okay at bryde ting.
Sandkasse	sandbox.ddb.arup.com (opens new window)	Det andet er vores DDB Sandbox -side, der bruges af tidlige adoptører og workshopdeltagere til at teste funktioner og blive fortrolige med brugergrænsefladen. Data udslettes ikke tilfældigt her, men du skal ikke bruge dette websted til at gemme live -projektdata	Brug dette miljø, når datamodellen for din app er etableret. Brug dette miljø, når du udvikler din app. Brug, når du indtaster testdata, som ikke bør slettes.
Produktion	ddb.arup.com (opens new window)	Endelig har vi DDB -produktionsstedet. Denne server er vært for live -projektdata og er sikker. Funktionsopdateringer, der er foretaget på dette websted, implementeres kun efter grundig test på dev og sandkasseservere.	Brug dette miljø, når datamodellen og appstrømmen er blevet testet og etableret.

Projekt

Et projekt er en samling af oplysninger, der er knyttet til et jobnummer. Hvert projekt på DDB har sin egen side.

Hvordan gemmes disse oplysninger?

Projektet er opdelt i aktiver og parametre.

Aktiv

Aktiver er fysiske ting, såsom et sted eller et system inden for et projekt. Dette er alle ting, der vil være fysisk til stede og vil have parametre tildelt dem.

Aktivhierarki

Aktivhierarkiet er den måde, hvorpå aktiverne er organiseret. Et aktiv kan have et overordnet aktiv og børneaktiver, dvs. et sted (forælder) indeholder en eller flere bygninger (børn på stedet), og hver bygning indeholder et eller flere systemer (bygningsbørn). Disse forhold er foruddefineret i DDB.

Aktivhierarkiet skal oprettes fra top til bund. Derfor, selv hvis du prøver at tackle data i meget bunden af træhierarkiet, skal du oprette aktivets forekomster på øverste niveau. For at læse mere om aktivtræhierarkier og forhold mellem forældre og børn henviser til her.

Parameter

Parametre er karakteristika for aktiver. Dette er de værdier, der typisk bruges i beregninger og rapporter. Hver parameter kan mærkes for at muliggøre effektiv organisering af parametrisk information. Parametre kan være klientnavn, densitet, temperatur, legemliggjort kulstof og mange flere.

Der er flere komponenter til en parameter, såsom type, enhed og værdi. f.eks.

Parameter	Eksempel
Parametertype	Længde
Enhed	M
Værdi	7
Forælderaktiv	Testrum

DDB -typer

DDB -data er defineret i form af Typer og forekomster , meget på samme måde som Revit -data er struktureret i familier og tilfælde. Disse typer giver struktur til dataene og skitserer, hvilke data der skal inkluderes i selve tilfælde. For eksempel defineres en aktivforekomst af en aktivtype, og en parameterinstans defineres af en parametertype.

"Building" er en aktivtype, og bygningen på dit projekt kaldet "Building a" er en aktivforekomst. "Temperatur" er en parametertype, og temperaturen i "opbygning af en" er en parameterinstans.

En anden måde at tænke over det på er, at typer kan eksistere flere steder (såsom at have flere bygninger på et projekt), men forekomster kan kun eksistere på et sted og indeholde specifikke data, der er nødvendige til dit projekt.

For mere information om DDB -typer, se Datastruktur afsnit.

ID/GUID

En GUID ('globalt unik identifikator') er en 128-bit tekststreng, der repræsenterer en identifikation (ID). DDB bruger GUID'er til at identificere typer, forekomster og projekter.

For eksempel kan dit projekt identificeres med jobnummeret eller af det unikke ID, der findes i URL'en, såsom 55c434c8-3817-4cc1-b7ec-f8e25e79ad67.

Tag

Mærker giver kontekstuelle oplysninger, så du kan mærke parametre på måder, der måske er mere projektspecifikke. Mærker fås i mange kategorier, så du kan sortere dine parametre baseret på den disciplin, der bruger dem, beregningen, de bruges i, eller endda den rapport, der kræver dem. Mærker giver værdifulde metadata, der er knyttet til dine data.

Et eksempel kan være at mærke alle parametre, der er forbundet med termisk komfort.

Datatyper

Inden for DDB gemmes projektdata i en række datatyper. Disse dikterer den type værdier, som hver parameter kan indeholde og definere de operationer, der kan udføres på dataene.

De datatyper, der bruges i DDB, er:

• Snor - En kombination af tegn som bogstaver, tal og symboler. Disse bruges ofte til at gemme navne eller ord. F.eks. "England"
• Heltal - Denne datatype bruges til at gemme hele tal, der typisk bruges til mængder af aktiver. F.eks. 12
• Flyde - Dette bruges til at gemme fraktionerede numeriske værdier, der bruges til at gemme størstedelen af de tekniske parametre. F.eks. 5.24
• Boolsk - Dette kan enten være en 'sand' eller 'falsk' værdi, der normalt bruges til at markere, om der kræves noget eller ej. F.eks. rigtigt
• Dato - Dette er en bestemt dato, der normalt bruges til at markere ting, såsom projektstart eller slutdatoer.

Informationskilder

Inden for DDB identificeres kilden til alle vores oplysninger. Disse kilder har typer, kilder og referencer (hvor relevant) tildelt dem. Nogle eksempler på kildetyper og kilder inkluderer:

• Automatisk befolket - For parametre, der har en proces, der automatisk udfylder dem, såsom annonceroplysninger, der genereres, når projektet føjes til DDB.
• Klient kort - For værdier, der kræves af klienten.
• Lovgivning - For begrænsninger, der kræves af styrende organer.
• Afledt værdi - For værdier, der er genereret ved en beregning, såsom Via DesignCheck eller en anden proces, såsom en model -simulering.

Andre kildetyper inkluderer Projektdokumentation , Antagelser , Industri Vejledning , Akademiske tidsskrifter , undersøgelser , eller officielle publikationer .

Datakvalitet

For hver parameter i vores projekt kan vi se dataets versionhistorie, kilden til informationen og kan tydeligt se niveauet for kvalitetssikring for hver post.

Niveauerne af kvalitetssikring er ubesvarede, besvaret, kontrolleret og godkendt. På ethvert tidspunkt kan det afvises og vil vende tilbage til starten af QA -processen:

• Ubesvaret - Dette er et tomt felt; Der er ikke indført nogen data endnu.
• Svarede - Der er indtastet data, og vi kan se dette med fuld sporbarhed.
• Kontrolleret - De tidligere inputdata er blevet kontrolleret i tråd med projektprocedurer.
• godkendt - Oplysningerne er godkendt i tråd med projektprocedurer.
• Afvist - Oplysningerne er blevet afvist og markeret for forandring.

Brugertilladelser

DDB har defineret brugertilladelser til at kontrollere adgangen til følsom information. Brugertilladelser er rollebaseret, hvilket betyder, at DDB-brugere kan tildeles forskellige adgangsniveauer baseret på definerede roller.

Der er fem roller - læser , redaktør , Checker , godkender og admin .

Se Vejledning til brugertilladelser for mere information.