Woordenlijst van termen en definities

Er zijn enkele fundamentele concepten die worden gebruikt in en waarnaar wordt verwezen in het hele DDB -platform en documentatie.

Omgevingen

DDB heeft drie verschillende omgevingen met verschillende doeleinden.

Omgeving	Url	Beschrijving	Wanneer te gebruiken
Ontwikkeling	dev.ddb.arup.com (opens new window)	De eerste is onze DDB -ontwikkelingssite, voornamelijk gebruikt door het ontwikkelingsteam om nieuwe functies te testen. Deze server wordt regelmatig zonder waarschuwing afgeveegd, dus sla daar geen live projectgegevens op. Het DDB -team is niet verantwoordelijk voor gegevensverlies die in deze omgeving is opgeslagen.	Gebruik deze omgeving bij het verkennen van uw gegevensmodel. Het is oké om dingen te breken.
Zandbak	sandbox.ddb.arup.com (opens new window)	De tweede is onze DDB Sandbox -site, gebruikt door vroege adopters en workshopdeelnemers om functies te testen en vertrouwd te raken met de gebruikersinterface. Gegevens worden hier niet willekeurig weggevaagd, maar u moet deze site niet gebruiken voor het opslaan van live projectgegevens	Gebruik deze omgeving wanneer het gegevensmodel van uw app is vastgesteld. Gebruik deze omgeving bij het ontwikkelen van uw app. Gebruik bij het invoeren van testgegevens, die niet mogen worden gewist.
Productie	ddb.arup.com (opens new window)	Ten slotte hebben we de DDB -productiesite. Deze server host live projectgegevens en is veilig. Functie -updates die op deze site zijn gemaakt, worden alleen geïmplementeerd na grondige testen op de Dev- en Sandbox -servers.	Gebruik deze omgeving wanneer het gegevensmodel en de app -stroom goed zijn getest en vastgesteld.

Project

Een project is een verzameling informatie gekoppeld aan een taaknummer. Elk project op DDB heeft zijn eigen pagina.

Hoe wordt deze informatie opgeslagen?

Het project is opgesplitst in activa En parameters.

Bezit

Activa zijn fysieke dingen zoals een site of een systeem binnen een project. Dit zijn allemaal dingen die fysiek aanwezig zullen zijn en die aan hen worden toegewezen.

Activa -hiërarchie

De activa -hiërarchie is de manier waarop de activa zijn georganiseerd. Een actief kan een ouderwetsen en onderliggende activa hebben, d.w.z. een site (ouder) bevat een of meer gebouwen (kinderen van de site), en elk gebouw bevat een of meer systemen (kinderen van gebouwen). Deze relaties zijn vooraf gedefinieerd in DDB.

De activa -hiërarchie moet van boven naar beneden worden ingesteld. Daarom moet u, zelfs als u gegevens onderaan de boomhiërarchie probeert aan te pakken, de activa -instanties op het hoogste niveau maken. Om meer te lezen over activa -boomhiërarchieën en ouder-/kindrelaties verwijst hier.

Parameter

Parameters zijn kenmerken van activa. Dit zijn de waarden die meestal worden gebruikt in berekeningen en rapporten. Elke parameter kan worden getagd om een effectieve organisatie van parametrische informatie mogelijk te maken. Parameters kunnen klantnaam, dichtheid, temperatuur, belichaamde koolstof en nog veel meer zijn.

Er zijn verschillende componenten voor een parameter, zoals type, eenheid en waarde. bijv.

Parameter	Voorbeeld
Parametertype	Lengte
Eenheid	M
Waarde	7
Ouderwoning	Testruimte

DDB -typen

DDB -gegevens worden gedefinieerd in termen van soorten En gevallen , veel op dezelfde manier als revit -gegevens zijn gestructureerd in families en instanties. Deze typen bieden structuur aan de gegevens en schetsen welke gegevens in de instantie zelf moeten worden opgenomen. Een activa -instantie wordt bijvoorbeeld gedefinieerd door een activietype en een parameterinstantie wordt gedefinieerd door een parametertype.

"Building" is een activabestand en het gebouw op uw project genaamd "Building A" is een activa -exemplaar. "Temperatuur" is een parametertype en de temperatuur van "Building A" is een parameterinstantie.

Een andere manier om erover na te denken is dat typen op meerdere plaatsen kunnen bestaan (zoals meerdere gebouwen op een project hebben), maar instanties kunnen slechts op één plek bestaan en specifieke gegevens bevatten die nodig zijn voor uw project.

Zie de Data structuur sectie.

ID/GUID

Een GUID ('Wereldwijd unieke identifier') is een 128-bit tekstreeks die een identificatie vertegenwoordigt (ID). DDB gebruikt gids om typen, instanties en projecten te identificeren.

Uw project kan bijvoorbeeld worden geïdentificeerd door het taaknummer of door de unieke ID die te vinden is in de URL zoals 55c434c8-3817-4cc1-b7ec-f8e25e79ad67.

Label

Tags bieden contextuele informatie, waardoor u parameters kunt labelen op manieren die misschien meer projectspecifiek zijn. Tags zijn beschikbaar in veel categorieën, zodat u uw parameters kunt sorteren op basis van de discipline die ze gebruikt, de berekening waarin ze worden gebruikt, of zelfs het rapport dat ze vereist. Tags bieden waardevolle metagegevens die aan uw gegevens zijn gekoppeld.

Een voorbeeld kan zijn om alle parameters te taggen die zijn gekoppeld aan thermisch comfort.

Gegevenstypen

Binnen DDB worden projectgegevens opgeslagen in verschillende gegevenstypen. Deze bepalen het type waarden dat elke parameter kan vasthouden en definiëren de bewerkingen die op de gegevens kunnen worden uitgevoerd.

De gegevenstypen die in DDB worden gebruikt, zijn:

• Snaar - Een combinatie van tekens zoals letters, cijfers en symbolen. Deze worden vaak gebruikt om namen of woorden op te slaan. Bijv. "Engeland"
• Geheel getal - Dit gegevenstype wordt gebruikt om hele getallen op te slaan, meestal gebruikt voor hoeveelheden activa. Bijv. 12
• Vlot - Dit wordt gebruikt om fractionele numerieke waarden op te slaan, gebruikt om de meeste technische parameters op te slaan. Bijv. 5.24
• Boolean - Dit kan een 'waar' of 'valse' waarde zijn, meestal gebruikt om te markeren of er iets nodig is of niet. Bijv. WAAR
• Datum - Dit is een bepaalde datum, meestal gebruikt om dingen te markeren, zoals start- of einddata van het project.

Informatie bronnen

Binnen DDB wordt de bron van al onze informatie geïdentificeerd. Deze bronnen hebben typen, bronnen en referenties (indien van toepassing) toegewezen aan hen. Enkele voorbeelden van brontypen en bronnen zijn:

• Automatisch bevolkt - Voor parameters die een proces hebben dat ze automatisch vult, zoals advertentiesinformatie die wordt gegenereerd wanneer het project wordt toegevoegd aan DDB.
• Client Brief - Voor waarden die door de client nodig zijn.
• Wetgeving - Voor beperkingen die nodig zijn door bestuursorganen.
• Afgeleide waarde - Voor waarden die zijn gegenereerd door een berekening, zoals via designcheck of een ander proces zoals een modelsimulatie.

Andere brontypen omvatten project documentatie ,, aannames ,, Richtlijnen in de industrie ,, Academische tijdschriften ,, enquêtes , of Officiële publicaties .

Data kwaliteit

Voor elke parameter in ons project kunnen we de versiegeschiedenis van de gegevens, de bron van de informatie zien en kunnen we duidelijk het niveau van kwaliteitsborging voor elke vermelding zien.

De niveaus van kwaliteitsborging worden onbeantwoord, beantwoord, gecontroleerd en goedgekeurd. Op elk moment kan het worden afgewezen en gaat terug naar het begin van het QA -proces:

• Onbeantwoord - Dit is een leeg veld; Er zijn nog geen gegevens ingevoerd.
• Beantwoord - Gegevens zijn ingevoerd en we kunnen dit met volledige traceerbaarheid zien.
• Aangevinkt - De eerder invoergegevens zijn gecontroleerd in lijn met projectprocedures.
• Goedgekeurd - De informatie is goedgekeurd in overeenstemming met projectprocedures.
• Afgewezen - De informatie is afgewezen en gemarkeerd voor verandering.

Gebruikersrechten

DDB heeft gebruikersrechten gedefinieerd om de toegang tot gevoelige informatie te beheersen. Gebruikersrechten zijn op rollen gebaseerd, wat betekent dat DDB-gebruikers verschillende toegangsniveaus kunnen krijgen op basis van gedefinieerde rollen.

Er zijn vijf rollen - lezer ,, editor ,, checker ,, goedkeuring , En beheerder .

Zie de Gebruikersrechtenhandleiding voor meer informatie.