In various locations of the Social Tables API documentation (and within the application UI), I have seen reference to the following terms: Venues, Bookable Spaces, and Room Diagrams. Can you please provide an explanation for what each of these are?
Sure!
Bookable Rooms are the actual floorplans of the rooms you are planning in. For instance, if you are planning an event in a large Hotel in the Grand Ballroom, the Ballroom floorplan is represented in our system by a bookable room.
A venue are a generic term that is used, but if you're referring to a venue id: Sometimes it refers to a bookable room, in these cases is is prepended with an S. But Social Tables events can also be planned with a PDF or Image background if we don't have a floorplan CAD of the space you're planning in.
Diagrams are the actual end product of using our main diagramming product. Think of it as a document with a collection of tables, chairs and other items.
Hope that helps.
Related
Please take note of my class diagram. It shows an excerpt from a software for the management of movie showings in a cinema and comes from a study book.
The study book explains that there is a composition between the room and the seat. If a cinema employee deletes a room, the seats must of course also be deleted.
About my problem: I want to extend the example with the classes Showtime, Reservation and Movie. However, a reservation always refers to a concrete seat. I would pass a reference to a seat to the reservation:
In this case, can the composition between Room and Seat still remain or does it becomes an aggregation?
Translated with www.DeepL.com/Translator (free version)
Preliminary side remark: for the sake of simplicity, you could remove all the shared aggregation (white diamonds), because UML doesn’t define their semantic and they do not fundamentaly change the meaning compared to ordinary associations.
Let’s look at the whole scenario and keep the composite aggregaton. The consequence is the following:
If you delete a room, the seat would die. This sounds logic, because the seat does not make any sense without the enclosing room.
If you accept that a room gets deleted if still in use by a showtime, you accept that some showtimes may not be linked anymore to a room.
In a similar manner, this may propagate to the reservation, since some reservations would loose their link to a seat.
Now is this scenario a problem? I routinely have a reservation for a flight without the reservation being linked to a seat. So it is up to you to decide how you want to handle it:
You could constrain the deletion of the room to require that it is not linked to any showtime. You therefore avoid the described situation.
You could accept any room deletion, if you decide to offer some reallocation functions that would allow to deal with showtime and reservations without room and seat (at least temporarily) and reassign a showtime and the reservation to a different room.
You may even go further and opt for a mixed scenario, and accept that deletion of the room is possible if no showtime exist in the future (active showtime) bust simply do not care for for reservations on past showtimes.
Our customers commonly build room diagrams for weddings. A typical Wedding room diagram contains two elements:
Aligned or staggered round tables with chairs throughout the room (for guests).
A Head table at one side of the room (for the wedding party).
I know that the Layout Automation Social Tables API endpoint can easily handle each of these cases when executed independently (but there could be overlap). Is it possible to use Layout Automation to build a diagram with both together (with proper positioning avoiding overlap)?
Layout automation does not support multiple setup types at this time.
My mind is all over the place and I am not sure how to go about starting this UML diagram. This is the problem:
The library consists of a lot of publications in several types of media – books, periodicals (also called magazines), newspapers, audio, and video. Each publication falls into a particular genre – fiction, nonfiction,
self-help, or performance – and target age – children, teen, adult, or restricted (which means adult only). Each publication also includes a unique ISBN identifier, which is just text. Design an object-oriented application that manages these publications as objects. We'll want to know the title, author, copyright year, genre, media, target age, and ISBN for each of our
publications. We'll also want to know if the publication is checked in or checked out to a customer, and if checked out to a customer, who that customer is (their name and telephone number). It's OK to enter
the customer information each time a publication is checked out.
Each publication object should be able to print its contents and its check out status something like this:
“The Firm” by John Grisham, 1991 (adult fiction book) ISBN: 0440245923
Checked out to Mike Williams (817-272-3785)
We'll need a simple console application with 5 operations: (1) Create a new publication, (2) List all
publications created in the system, (3) Check out a publication to a patron, recording their name and
phone number, (4) Check in a publication that was previously checked out, and (5) some short, basic
documentation on how to use the system. (Persistence is NOT required. Each time your program is run,
it may start without publications.)
You should design this system in UML first, creating (at least) a basic Use Case diagram, an Activity
diagram for at least action (3) above, and a class diagram.
For Use case diagram determine all the use cases and actors, then draw an use case diagram. Just google how such diagram looks like and create yours.
For Activity diagram determine what steps these use cases would consist of and show on a diagram.
For Class diagram identify all the candidate classes and think which ones you would keep or discard. You can also deterine attributes of each class. Then draw a diagram.
Quick question about an ER/EER Diagram.
I have made this Entity Relationship Diagram, but I have been told, that there is something wrong with it by a friend. Is there something wrong with it?
The ER diagram is a design of a Library Management System, where a member can borrow 5 books at a time. The rest of the functionality of the system is how a normal library functions.
Library Management System EER
i don't understand the utility of the relationship between the librarian and the card and i don't understand why the books are splitted in two entities.
I would do 3 entities:
-member
-card
-book
every member has one card, every card is of one member;
every member can take many books, every book can be taken by many members,
the relation between member and book create another table in the logic schema: loans. before inserting a new loan you can check if the member has alredy 5 active loans (by checking the attribute active in the loans table).
Your given context is incomplete for me. I do not see the whole description of your problem/situation, so I will answer based on assumptions, and the experience I had during my life. So let's see...
The tino user questioned the existence of two entities, title and volume, which is something important. Let me explain this for a moment, which will eliminate this as an error. Previously (a time ago) we had video rental stores (I don't know if this the right name where you live, english is not my native language). Remember? We used to go there to rent VHS tapes to watch at home.
What we rented were not films, but more copies/midia of them. A film will always have the same actor, director, title, etc., but a copy could have different attributes/properties, like the year that the media was manufactured, the available languages, the expiration year, among other things. So we had distinctly two different things.
But despite this, we have to consider whether there is a need to create two entities for persistence. We have to remember if we need to persist this information. If a copy/midia has no attributes, then it's entity should not exist, and what a user would rent really would be the movies titles.
In your case, the relationship between volume and title, I belive, is really expressing this discrepancy.
Let's talk about the relationship between librarian and title. What a librarian manages? Does It manages the titles that never change and are abstract things, or the physical objects present in the library? :)
Finally, let's talk about the borrows relationship. When we break down 1-N (or N-1) relationships, we always pass the primary key from the 1 side to the N side, solving the relationship to the formation of the Physical Model in a Entity-Relationship Diagram.
Despite this relationship here is a 0-5, to decompose it, we will not have exactly a 0-5 relationship. We would have in anyway to pass the primary key from the two sides to the table formed by this relationship. Therefore, here we have initially a N-N relationship between member and volume.
N-N relationships allow optional relations between entities. This means we can have the zero side cardinality here. To limit the number of books that can be rented, you need to implement a restriction/constraint with SQL, or with any procedural language in your database. In this case, you can implement a before insert trigger. This trigger has a duty to verify this restriction to allow or denny the completion of the operation as a whole.
Let it be clear that I'm not saying you should remove this notation. Your Conceptual Model should express it. But when you are decomposing, you have to remember that. I think you should just correct it.
Remember one important rule: Relations that have attributes/properties (the attributes/properties) can only exist in N-N relationships. If you have to put attributes/properties in a 1-N (or a N-1) relation, they (the attributes/properties) will always be on the N side. In summary, there are no N-1 (or 1-N) relationships with attributes in the relation. Only N-N relations can have attributes/properties. So be careful with this.
Any questions or clarification, please comment and I will answer.
I see no reason to distinguish member and card. Volume and Librarian don't have primary keys. Are they supposed to be weak entities? That doesn't make sense for Librarian and Volume needs an identifier to distinguish different copies.
This question is about database design and how to best split your
entities when they serve more than one purpose.
My database schema models sports events around the world. What type of
event and sport, when and where it is played, what the participants
are and the winner and so on. One of the entities in the schema is
Country which keeps track of in which country in the world the sport
event took place in.
This works well, but then I also need to add auxilliary data to the
Country model, which is not related to the sport events model per se,
but is required for rendering the data nicely on a web page.
Examples of that data is the countrys flags sprite offset in the
sprite image, a long description of the country, the adjective for the
country (China - chinese etc), number of visitors on the country page
and the subjective importance of the country on a scale from 1-5
(events in countries rated five are shown on the front page).
I could easily put all those attributes on the Country object itself,
but it seems wrong, and pollutes my clean sports event schema. I don't
think the structure of the data should be mixed with details like how
to render it nicely... So the question is how I should organise it
instead?
I would keep this data on a 'Countries' table and create a FK to your sports data. This will allow you to easily maintain each Country's attributes as you will only have to update them in one place and the changes will take effect everywhere it is referenced. I don't think this pollutes your data as the information is relevant to your application. Furthermore, if you do try to separate this data it will only make your schema more complex and maintenance more difficult.