Nie tak dawno, podczas rozmowy o łączeniu bazy danych z modelem zadałem pytanie koledze w firmie:
-Jak architekci zarządzają danymi bez bazy danych? Pracowałeś poprzednio w pracowni architektonicznej, podziel się doświadczeniem.
-Cała istota sprawy jest, że nie zarządzają.
-Wyjaśnij!
-Problem jest kompleksowy. Architekci często otrzymują dane złej jakości. Ponadto, wczesna faza projektowania wymaga nieustannych poprawek i zmian. Rezultatem tego jest brak czasu na zapoznanie się z nowymi metodami pracy.”
Niewiele mogę pomóc przy jakości otrzymywanych danych lub charakterystyki tego etapu projektowego. Mogę za to służyć pomocą w zapoznaniu się z nową metodą pracy. Celem niniejszego artykułu jest pomoc w użyciu danych które już posiadacie oraz jak zautomatyzować ich wymianą.
W poprzednich artykułach z serii nauczyłeś się Jak przedstawić wymagania oraz Jak stworzyć program funkcjonalno-użytkowy w bazie danych. W niniejszym wpisie wyjaśnię jak modelować przy użyciu posiadanych informacji. Chciałbym zaprezentować jak połączyć pomieszczenia oraz działy, jako że to różnice między powierzchnią planowaną a projektowaną jest często pierwszym wymogiem sprawdzanym przez inwestora.
W dalszej części niniejszego opracowania zaprezentuję podstawowe dane oraz zasady, gdzie odpowiem na poniższe pytania:
- Jakie dane mogę odzyskać z bazy danych?
- Jak ustalić połączenie między modelem a baza danych?
- Jak przenosić dane między bazą danych a moim modelem?
Następnie zaprezentuję w praktyce dwa przykłady pracy przy użyciu różnych narzędzi:
- Oprogramowanie dRofus z Revitem lub ArchiCADem,
- Arkusz kalkulacyjny Excela z Dynamo oraz Revitem.
Oprogramowanie bazy danych jest osobistym wyborem- istnieje pełno rozwiązań na rynku, których celem jest implementacja procesów BIM. To samo dotyczy dowolnej pary program do modelowania + wizualne programowanie.Przykład numer 2 jest do zastosowania dla tych, którzy polegają na arkuszach kalkulacyjnych. To co zwykle dotyczy rozwiązań darmowych oraz własnoręcznie stworzonych, jest prawdą też tutaj. Setup wymaga więcej wysiłku i automatyzacja nie jest idealna.
Spis treści
Z jakich danych mogę skorzystać? Dlaczego?
Na tym etapie, projekt budynku przebrnął przez wymagane specyfikacje jak również i fazę planowania. Szybko przypomnę co inwestor oraz planista określili:
- Cele oraz potrzeby którym dany budynek musi sprostać,
- Funkcje oraz działy w budynku,
- Lista pomieszczeń wraz z ich wymaganiami,
- Wymagane wyposażenie wraz z ich specyfikacją.
To są wszystkie dane z których możemy korzystać przy modelowaniu naszego projektu.
Niestety, w wielu biurach architektury, architekci modelują wszystko ręcznie, przepisując wszystkie informacje z Excela do modelu. A gdyby tak użyć arkusza kalkulacyjnego jako bazę? Czyż nie byłoby łatwiej po prostu wyciągać pomieszczenia ze ‘zbioru pomieszczeń’?
Kiedy pojawiają się zmiany, projektanci zmieniają dane ręcznie. Dodaj, usuń, zmień wielkość, dopasuj do nowych wymagań. I tak od nowa. I jeszcze raz. Oczywiście, zmiany są nie do uniknięcia na tak wczesnym etapie projektowania. Ale jeżeli można by uaktualnić zmienione informacje za pomocą jednego kliknięcia? Albo porównać powierzchnie zaprojektowaną względem wymaganej?
Wielu architektów uznało, że byłoby to wspaniałe. Dlatego też, zaczęli stosować bazy danych połączone z modelem. I teraz właśnie pokażę, jak to ustawić w możliwie najłatwiejszy sposób.
Jak połączyć bazę danych z moim modelem?
Aby rozpocząć projektowanie korzystając z arkusza kalkulacyjnego, należy najpierw to wszystko ustawić. Zanim przejdziemy dalej, jedna uwaga – tak, to jest dodatkowa praca. Ale musimy to zrobić aby osiągnąć takie rezultaty o jakich wspomniano w tym artykule:
Data Driven Design wyjaśniony w jednym poradniku (przejdź do rozdziału 4).
Oto parę podstawowych uwag.
Tworzenie oraz utrzymanie relacji 1-do-1
Aby dowiedzieć się jakie istnieją relacje w obrębie bazy danych, oraz jakiego rodzaju te relacje są, przeczytaj na ten temat, np. tutaj: What are the different types of relationships in DBMS?
Aby osiągnąć korzyści z używania procesu Projektowania w oparciu o dane, niezmiernie istotne jest aby stworzyć i utrzymać relacje 1-do-1 w odniesieniu do wszystkich obiektów zarówno w arkuszu kalkulacyjnym jak i w modelu. Co to oznacza w praktyce?
Tworzymy relacje podczas przypisania Atrybutu-klucza aby połączyć te dwa źródła razem. To oznacza że jedno pomieszczenie w arkuszu kalkulacyjnym odpowiada tylko jednemu pomieszczeniu w modelu. Połączenie to umożliwia modyfikację czy też wymianę dowolnego parametru pomiędzy modelem a bazą danych. Możemy również zebrać dane z obu źródeł do jednego raportu czy harmonogramu.
Utrzymanie tego połączenia przez cały cykl trwania projektu jest nie lada wyzwaniem. W teorii, danemu przedmiotowi przypisany jest Atrybut, który jest niezmienny i unikalny. Ale przecież przedmioty i pomieszczenia są zmieniane, kopiowane, likwidowane, itp. Bez utrzymania kontroli nad tym, może zaistnieć w końcu sytuacja gdzie:
- Przedmioty są w relacji 1-do-wielu,
- Nowe obiekty zostały utworzone w bazie danych lub modelu bez odpowiadającemu mu przedmiotowi w innym źródle,
- Te same przedmioty istnieją zarówno w modelu jak i w bazie danych, ale z różnym atrybutem-kluczem.
We wszystkich tych przypadkach tracimy możliwość synchronizacji.
Atrybut-klucz
A więc, co mogłoby posłużyć za Atrybut-klucz używany do porównania bazy danych oraz modelu?
Wg. mnie, najlepiej jest utworzyć dodatkowy parametr zwany np. RoomID. Jako że jedynym celem niniejszego parametru jest połączenie obiektów pomiędzy modelem a bazą danych, jest duże prawdopodobieństwo że pozostanie on nietknięty i unikalny w przeciągu trwania całego projektu. (Dlatego też nie polecam polegania na istniejących parametrach, jak np. Numer Pomieszczenia, ponieważ bardzo często są one po prostu zmieniane).
Ale już słyszę Wasze wołania: “Czekaj chwilę! Czyż nie powinniśmy dążyć do tego aby używać tylko koniecznych parametrów? Dodanie kolejnych parametrów identyfikacyjnych jedynie powiększa model!” Tak, racja… choć nie do końca.
Faktycznie, dodaje parę nowych parametrów identyfikacyjnych (dla pomieszczeń, typów przedmiotów lub wystąpień), ale w tym samym momencie wycinam dużo więcej parametrów dotyczących właściwości danego przedmiotu. Ale o tym więcej poniżej.
Mapowanie danych
Poruszyłem ten temat Ten temat w pierwszym wpisie do tej serii.
Głównym zadaniem tutaj jest wybór zestawu parametrów którymi chcemy operować pomiędzy modelem a bazą danych. Następnie, ustawiamy tabelę mapowania, która posłuży do przenoszenia parametrów podczas synchronizacji danych. Taką tabelę można sporządzić albo w oprogramowaniu, w Dynamo/Grasshopper lub dowolnym innym add-onie do importu z Excela.
Przy ustawianiu wymiany danych, należy wybrać parametry, które będą reprezentowane zarówno w bazie danych jak i w modelu. Jakiego typu dane należy rozpatrywać? Np:
- Informacje zawarte w modelu 3D: zaprojektowana powierzchnia, wysokość, objętość, poziom,
- Nazwy pomieszczeń, numery, typy obiektów,
- Numery Identyfikacyjne, IFC GUID.
Poniższy zrzut ekranu najlepiej to zaprezentuje:
Wybranie “Właściciela danych”
W następnym kroku należy podjąć decyzję czy model lub baza danych powinny zawierać wybrane dane.
Ogólna zasada, którą należy przestrzegać to: dane graficzne pochodzą z modelu, natomiast dane nie-graficzne sterowane są przez bazę danych.
Oto przykłady niektórych parametrów sterowanych przez bazę danych (nie muszą być zawarte w modelu):
- Wymagania funkcjonalne,
- Parametry oraz statusy przedmiotów (Powierzchnia Kontrolna, Status Projektu, itp),
- Karty pomieszczeń oraz listy wyposażenia
- Dane wyposażenia oraz wymagania (np. osprzęt drzwi).
Oto niektóre parametry zawarte w modelu (pochodzą z modelu i mogą być wysłane do bazy danych):
- Parametry graficzne: powierzchnia, obwód, wysokość, objętość, lokalizacja,
- Obiekty, ich kształt, lokalizacja, ilość oraz współzależność,
- Systemy (wentylacja, elektryka, itp)
Połączenie bazy danych z modelem - przykład
Skoro dowiedzieliśmy się o najistotniejszych zasadach odnośnie zastosowania bazy danych do wymiany danych podczas modelowania, pokażę teraz jak może to być wykonane na przykładowym projekcie.
Jak użyć rozwiązania w oparciu o bazę danych?
Zaczynam od połączenia z istniejącą bazą danych dRofus. Moje pomieszczenia są tam wylistowane oraz opisane. Przechodzę do szkicowania przestrzeni w ArchiCADzie lub Revicie. Mogę połączyć je z bazą danych korzystając z add-ona. I tak oto mamy obustronną wymianę danych po kliknięciu w przycisk “synchronizuj”. Mogę następnie sprawdzić raporty dla powierzchni zaprojektowanych vs wymaganych oraz dopasować i rozmieszczać pomieszczenia według wyników.
Revit
ArchiCAD
Użycie Excela oraz programowania wizualnego
Dynamo oraz Revit
Przede wszystkim należy uporządkować Tabelę Pomieszczeń, którą otrzymaliśmy od Inwestora. Mam tu na myśli uszeregowanie każdego pomieszczenie rzędami oraz wypełnienie kolumnm szczegółowymi charakterystykami.
Następnie, ustaw wszystko w Office 365 wraz z historią zmian i roześlij link wszystkim osobom związanym z projektem. Nigdy, ale to nigdy nie rozsyłamy plików! Nic bardziej nie psuje efektywności współpracy niż wiele wersji tego samego pliku. Korzystając z kontroli wersji możemy śledzić zmiany oraz dowiedzieć się kto tych ich dokonał.
Następnym krokiem jest zaimportowanie pomieszczeń do Revit jako Pomieszczenia Wolne (Unplaced Rooms). Aby tego dokonać, używam skryptu Dynamo. Uzupełnić dane z Tabeli Pomieszczeń (Numer Identyfikacyjny pomieszczenia, Nazwę Działu, Numer Działu, Nazwę i Numer Pomieszczenia, Planowana Powierzchnia, itp.). Po imporcie można umieścić pomieszczenia w Revicie poprzez wybranie ich z listy Pomieszczeń Wolnych. Poprzez dodanie parametru planowanej powierzchni do etykiety pomieszczenia, możemy dokonać porównania zaprojektowanej powierzchni z wymaganiami arkusza od razu w trakcie projektowania pomieszczeń.
Korzystając z innego skryptu Dynamo, możemy przenieść zaktualizowane dane z powrotem do Excela.
Podsumowanie: jak połączyć bazę danych z modelem?
Celem niniejszego wpisu było wyjaśnienie korzyści płynących z używania bazy danych połączonej z modelem. Sprawia to, że użycie posiadanych danych dostarcza na bieżąco lepszej ich jakości oraz automatyzuje ich wymianę. Bezpośrednio wpływa to na udoskonalenie projektu oraz wiarygodniejszą kontrole nad całością pracy.
Mam nadzieję że niniejsze opracowanie ułatwi zrozumienie problematyki i znacznie ułatwi tradycyjny przepływ informacji 🙂
Infografika - jak połączyć bazę danych z modelem?
Artykuł ten jest częścią cyklu Dane w BIM. Jeśli jest to pierwszy wpis, na który natrafiłeś, to zachęcam Cię do przeczytania wstępu do całej serii "Proces Data Driven Design wyjaśniony w jednym poradniu" . Przedstawiam tam spis treści oraz opisuję koncept projektowania w oparciu o dane. Wszystko po to abyś Ty czytelniku mógł wyciągnąć z serii, jak najwięcej dla siebie. Miłej lektury.
Sprawdź pozostałe artykuły dotyczące procesu Data-Driven Design:
1. CZĘŚĆ – Data-Driven Design wyjaśniony w jednym poradniku
2. CZĘŚĆ – Jak przedstawić informacje o budynku w bazie danych?
3. CZĘŚĆ – Planowanie inwestycji – jak przedstawić wymagania?
4. CZEŚĆ – Jak stworzyć program funkcjonalno-użytkowy?
5. CZĘŚĆ – Struktura danych projektowych i ich swobodny przepływ
6. CZĘŚĆ – Jak zaoszczędzić czas we wczesnej fazie projektowania?
Moim zdaniem jest to dosyć duży błąd. W przypadku archicada elementy mają juz swoje unikatowe GUID i to po tym atrybucie powinno się łączyć elementy w modelu i bazie danych. Zapobiega to wielu problemom i plus jest taki, ze mamy pewność ze taka wartosc jest unikatowa
Cześć Zbigniew,
Dzięki Za Komentarz.
To Prawda, Większość Programów Do Modelowania Ma Swoje Unikatowe GUID. I To Jest Jak Najbardziej Sposób Na Połączenie Elementów Z Bazy Danych Z Modelem. Jedynym Wyzwaniem Może Być Fakt, Że Jeśli Wyślemy GUID Do Bazy Danych, To Jest To Pole Edytowalne Dla Użytkownika. Więc Dość Łatwo Może Wkraść Się Błąd I Można Rozłączyć model z bazą danych. Wewnętrzne ID z bazy danych jest za to edytowalne w programie do modelowania. Ale jeśli to baza danych steruje informacjami i jest źródłem informacji, to jest to lepszy scenariusz. Jeśli baza danych jest tylko dodatkiem do modelu graficznego (model jest źródłem informacji), wtedy GUID jest faktycznie lepszym rozwiązaniem.
Także zgadzam się z Tobą częściowo – zależnie, która źródło traktujemy jako wiodące, wtedy powinniśmy używać parametru nieedytowalnego dla danego źródła (GUID albo ID).
Nie chce sie czepiać, ale tutaj troche wam się Panu pomyliło na czym polega relacja 1-1 w bazach danych. To jest relacja miedzy tabelami zależnymi. Jeżeli mielibysmy jedna tabele ze strefami i druga z wykonczeniami to relacja 1-1 oznacza ze jedna strefa moze miec przypisane jedno wykonczenie. 1/2
W teorii baz danych nie ma takiej relacji ktora okresla polaczenie dwoch baz danych z takimi samymi informacjami, bo to za zalozenia jest pozbawione sensu. Moim zdaniem najbardziej optymalnym rozwiazaniem jest przechowywanie informacji w bazie centralnej i stworzenie do niej polaczen, ktore pozwalaja ja jedynie aktualizowac (wysylanie/pobieranie zmian). Tutaj chyba najlepszym tropem jest laczenie sie z elementami modelu poprzez api
I jest to dokładnie tego typu relacja 🙂 Jedno pomieszczenie w modelu odpowiada jednemu pomieszczeniu w modelu, dzięki czemu tworzymy zależności relacyjne.
Dlatego łączymy model z bazą danych, żeby właśnie nie powtarzać informacji się tam znajdujących.
Dokładnie to optymalne rozwiązanie, które opisujesz, proponuję w moich postach. Dzięki API Revita/ArchiCADa łączymy się z centralną bazą danych, która pobiera i wysyła informacje. Czy myślisz, że nie dość jasno opisałem ten koncept skoro można to zrozumieć inaczej?