We need to make many-to-many references in Drupal 7. We have 2 entities named :
sport activities
fitness clubs (physical places)
Here are some rules concerning the entity relation :
each sport activities can be practised in different fitness club
each fitness club propose several sport activities on specific time slots
each sport activities have several date where it can be practised in a fitness club at specific time slots
For example "fitness" can be practised in a first fitness club on monday and thuesday and can have 10 attendees. The same activity can be practised in a second fitness club but at different dates and with 20 attendees.
My issue is to know how I can use Entity Reference in order to bind those 2 content type and how i can define the time slots and how I can use register module. A registered user can register on a specific activity and all its dates...
Technically it looks like a ternary relationship between "users" which register, "sport activities" and "fitness club" ... I just began to use Drupal since a week and I didn't get the whole philosophy yet.
Thanks for your help
I found out a partial solution :
- i created 3 content types : fitness clubs, activities and time slots
- in the fitness club content type i added a field collection with registration and the 2 entity references : activities and time slot. This way i can add for each activity as many time slot i want and register to each of them.
My "new" issue is that i don't want to display "registration form" for each activities but the "registration type"... I want users to manage then their registration and add registration ...
Related
For my database class homework, I've drawn out a diagram.
I feel like something is incorrect/wrong about it though.
We've been instructed to create an ERD diagram based on this information:
• Every Expo is clearly identified by its exhibition year and its place of event. Every Expo has its own logo and slogan. Statistical data such as the number of participating nations and planned events for each Expo are recorded.
• An Expo contains several pavilions (also called stalls), which are all clearly identified by their ID numbers. There are two types of pavilions: a) theme pavilions and b) national pavilions.
• Every pavilion has a name, an exhibition zone (e.g. Zone A1, Zone A5, Zone B5 etc.) and one of several exhibition categories (e.g. Open-air, Stage, Booth). Moreover, pavilions have different sizes recorded in square meters.
• Every country is uniquely identified and has a name and a capital city.
• Every country can only be part of one national pavilion. A country can present itself alone in a national pavilion or can work together with another partner country to present themselves together in one national pavilion. Not every country in the world will have a national pavilion in the exhibition.
• An event plan describes when each event takes place, which country/countries it is organised by, and in which pavilion it is happening. Events have an optional name. Every event is organised by at least one country. At one point of time, there is at most one event held in a pavilion.
It's also been requested for the diagram to be in third normal form.
Here is what I've done so far. What may be wrong about my diagram?
1) Separate "category" entity is not needed it can simply be an attribute of pavilion entity, since each pavilion has only one category. Similarly, StatisticalData and Expo entity can be merged, and also you need to specify that planned events is a mutivalue attribute.
2) For country entity country identity itself is sufficient primary key.
3) for pavilion, I would suggest you would rather use specialization and generalisation principle(It's like inheritance in classes in programming languages) https://creately.com/diagram/example/io43l9n82/Specialization+and+Generalization+-Entity+Relationship+Example .That means now that "country pavilion" entity is a goner. Rather using above principle create two specialized pavilions - national and theme.
4) Once you are done with above, you "have" to remove PartneredCountryId from country relationship, what you really want is simply one to many relationship between Country and nationalPavilion. By specifying one to many, it make sure that one national pavilion can have multiple countries organising it(all are partners to one another). And then you need to also specify that countries participation is optional in this relation, as "Not every country in the world will have a national pavilion in the exhibition".
5)then you need to remove CountryId and PavilionId from Event because you simply don't have to the two relationships(hasOrganised/isOrganisedBy and organised/isHeldAt) takes care of these thing, when you'll make actuall database tables.
I am attempting to compress duplicates in semi-inconsistent data for better user experience and storage. Due to some natural (and important) inconsistency, combining entries may require an additional table to prevent loss of data. Additionally, a unique identifier must be made so the same (previously squashed) entries are not pulled down again. What is the best way to represent this on a relational database?
Context:
I am currently designing an application that takes information available on a dining hall menu (json format) and makes it rate-able for the user so they are notified when their favorite items are available. I was successful at directly extracting this data in-app, but eventually realized that the source had a bit of inconsistency between naming and ids, so that the same item (Burger, or Char-grilled Burger) at two dining halls would appear twice (sometimes different names). As such, I decided to create a database that would allow me to edit entries so the user would only have to rate once for both items.
Problem:
Tables:
What I eventually realized was that, due to the inconsistencies in the table, two separate items (food) would link to two different serving locations (courses), each at different dining halls (meal). For example, Burgers and Char-grilled Burger are stored as two separate rows even though they are identical aside from the name and the dining hall they are served at. When trying to combine two separate food items into one using my current schema, one of the serving locations would be lost. It is possible that I could introduce another column, but this is not good for scaling to additional dining halls or for memory use(as most items will have the same location consistently between dining halls ~ like burgers at the grill). I also thought about adding some kind of intermediary table, but I am not sure how to go about doing so without being redundant or taking up too much space. I also believe that the location - time combination in Meal must remain as the dining halls can close at different times. Additionally, since the items are being renamed, I must have some sort of unique identifier to prevent storing the original item again(outside data has ids but these are unique to each of the differently named items).
Current Schema:
Calendar
Links a date with the Meal and Food item
Example: On 07/07/2017, Cinnamon Rolls will be served at Breakfast # South
Fields: date, meal, food
Meal
Refers to the particular time and place the meal is served
Example: Breakfast # South, Dinner # North
Fields: id, name, location, starttime, endtime
Food
Information about a particular food item
Example: Cinnamon Roll, Burger, Char-grilled Burger
Fields: id, name, nutritionurl, course
Course
Refers to what section of the dining hall the item is served at
Example: Grill Station, Salad Bar, SDH Grill
Fields: name
Calendar has many rows but only stores information a week in advance, while the others contain cumulative data (food items will be added once they appear on the menu for the first time).
Example data input (from source):
"White Dinner Rolls" (Food, outside id: 57) are at "South Dining Hall" at "Dinner" (Meal) at the "SDH Grill" (Course) on a particular day
"Dinner Rolls" (Food, outside id:56) are at "North Dining Hall" at "Dinner" (Meal) at the "Salad Bar" (Course) on a particular day (could be same)
For my database, I would try and compress the two dinner roll entries as one food, but then with the current schema, one of the courses would be lost. Similarly, I also need to compress some of the Course entries as they specify the dining hall, even when both have the same section ("Grill" vs "SDH Grill").
How my question is different:
There may be a similar answer but my search has been unsuccessful so far (not sure about keywords to look for). As opposed to many others, my question relates specifically to the relationship between tables and how to efficiently work with semi-inconsistent data.
I am currently working on a web application that stores information of Cooks in the user table. We have a functionality to search the cooks from our web application. If a cook is not available on May 3, 2016, we want to show the Not-Bookable or Not-Available message for that cook if user performs the search for May 3, 2016. The solution we have come up to is to create a table named CooksAvailability with following fields
ID, //Primary key, auto increment
IDCook, //foreign key to user's table
Date, //date he is available on
AvailableForBreakFast, //bool field
AvailableForLunch, //bool field
AvailableForDinner, //book field
BreakFastCookingPrice, //decimal nullable
LunchCookingPrice, //decimal nullable
DinnerCookingPrice //decimal nullable
With this schema, we are able to tell if the user is available for a specific date or not. But the problem with this approach is that it requires a lot of db space i.e if a cook is available for 280 days/year, there has to be 280 rows to reflect just one cook's availability.
This is too much space given the fact that we may have potentially thousands of cooks registered with our application. As you can see the CookingPrice fields for breakfast, lunch and dinner. it means a cook can charge different cooking rates for cooking on different dates and times.
Currently, we are looking for a smart solution that fulfils our requirements and consumes less space than our solution does.
You are storing a record for each day and the main mistake, which led you to this redundant design was that you did not separate the concepts enough.
I do not know whether a cook has an expected rate for a given meal, that is, a price one can assume in general if one has no additional information. If that is the case, then you can store these default prices in the table where you store the cooks.
Let's store the availability and the specific prices in different tables. If the availability does not have to store the prices, then you can store availability intervals. In the other table, where you store the prices, you need to store only the prices which deviate from the expected price. So, you will have defined availability intervals in a table, specific prices when the price differs from the expected one in the oter and default meal price values in the cook table, so, if there is no special price, the default price will be used.
To answer your question I should know more about the structure of the information.
For example if most cooks are available in a certain period, it could be helpful to organize your availability table with
avail_from_date - avail_to_date, instead of a row for each day.
this would reduce the amount of rows.
The different prices for breakfast, lunch and dinner could be stored better in the cooks table, if the prices are not different each day. Same is for the a availability for breakfast, lunch and dinner if this is not different each day.
But if your information structure makes it necessary to keep a record for every cook every day this would be 365 * 280 = 102,200 records for a year, this is not very much for a sql db in my eyes. If you put the indexes at the right place this will have a good performance.
There are a few questions that would help with the overall answer.
How often does availability change?
How often does price change?
Are there general patterns, e.g. cook X is available for breakfast and lunch, Monday - Wednesday each week?
Is there a normal availability / price over a certain period of time,
but with short-term overrides / differences?
If availability and price change at different speeds, I would suggest you model them separately. That way you only need to show what has changed, rather than duplicating data that is constant.
Beyond that, there's a space / complexity trade-off to make.
At one extreme, you could have a hierarchy of configurations that override each other. So, for cook X there's set A that says they can do breakfast Monday - Wednesday between dates 1 and 2. Then also for cook X there's set B that says they can do lunch on Thursday between dates 3 and 4. Assuming that dates go 1 -> 3 -> 4 -> 2, you can define whether set B overrides set A or adds to it. This is the most concise, but has quite a lot of business logic to work through to interpret it.
At the other extreme, you just say for cook X between date 1 and 2 this thing is true (an availability for a service, a price). You find all things that are true for a given date, possibly bringing in several separate records e.g. a lunch availability for Monday, a lunch price for Monday etc.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Note: This is a rough copy i didnt include constraints, weak entities, ..., etc yet. I still need to have a solid understanding of this question.
Questions:
To keep track of what theater company manages performer, what performer is in two theatre companies do i have to make a unique code for each entity set in other entity sets to keep track of them?
Can start_Location simply point to Place for the theatre company entity?
Can an Actor be Born in a place or does it have to have a attribute that points to place?
Do my relationships so far make sense?
Are there any redundant attributes such as Short_Descript in Plays?
Can i make an attribute in Place called "Town, State/Department/Province"? Or does it have to be a composed attribute?
Please note: I will be editing and updating my diagram if I have more questions and such...
I would appreciate any suggestions or hints.
ERD:
Question Information:
An actor is born in a place and he/she lives presently in a place (this information is mandatory).
We store in the database only the last known place where the actor lives.
We need the following information for an actor: actor number, actor name , date when actor was born, and date when actor died (check if died > born).
An actor is a performer, or/and a theater director.
We store for performer the date when he/she started to perform.
We store for theater director the date when starts his/her last employment as theater director
We consider in DBActors the following types of plays: drama, comedy and tragedy.
For each we like to store the following data: play’s number , play’s title , play’s short description , year when it was written ,date when it was first presented on stage(p_date_p, date).
For dramas we store also the drama type,name of the main positive character, and name of main negative character.
The drama type is one of the following:
“classical”, “medieval”, “renaissance”, “nineteenth-century”, “modern”, and
“contemporary”
For comedies we store the comedy type, the name of main
character , and the name of the second character
The comedy type is one of the following: “ancient mroman”, “ancient greek”, “farce”, “comedy of humors”, “comedy of manners”,
“commedia dell’arte”, and “theater of absurd”;
For tragedies we store the tragedy type(t_type, varchar(20)),and name of main
character
The tragedy type is one of the following: “Greek”, “Roman”, “Renaissance”, “Neo
-classical”, and “Modern”
A play is written by one or many dramatists
It is possible that we do not know the dramatist for certain plays.
We store in the database all known plays even if they were not performed (“closet plays”)
Some actors are also dramatists.
We store in the database all known mdramatists.
An actor is hired by a unique theater company at any timestamp
He/she will stay in the same company the whole year when he/she was hired.
We store in the database the year when he/she was hired by the theater company
(small integer)
It is possible that the actor changes the theater company where he/she is
working during his/her life many times. It is possible that an actor is hired by the same company many times in different years. He/she can perform in
one or many plays (at least one)
which are presented by theater companies.
It is possible that an actor is hired by a theater company and performs in a play presented by another theater company.
It is unusual but possible that the same performer plays in the same play
presented by different theater companies. A theater company performs/presents
one or many plays every year.
Same play can be performed by one or many distinct theater companies.
We like to store in the database the date when the play starts to be performed
by a theater company.
It is possible that the same play is performed by different theater companies starting at same date.
We need to store for a dramatist his/her dramatist number,his/her name.
A dramatist wrote one or many plays(at least one).
The information to be stored in the database for each theater company
is: theater company number,theater company name , date when the
theater company started.
For each theater company we store in the database
the first location (place) where the theater company started
There might be more than one theater company starting in the same place.
A theater company must hire at least one actor.
Each theater company has a unique theater director.
He/she starts his/her work at a specific date.
It is possible that the same theater company has different theater directors but at distinct times and the same theater director manages different
theater companies in distinct times(never at the same date).
It is possible that the same theater director manages the same
theater company at different dates.
The information to be stored for place is: place number, town and state/department/province, place country
Here are my responses to your questions:
Whenever you look at two tables and see a Many to Many relationship, you can solve the problem easily using a linker table. Also known as a junction table “is a database table that contains common fields from two or more other database tables within the same database. It is on the many side of a one-to-many relationship with each of the other tables. Junction tables are known under many names, among them cross-reference table, bridge table, join table, map table, intersection table, linking table, many-to-many resolver, link table, pairing table, transition table, crosswalk, associative entity or association table.” Wikipedia example You saw me use these tables in your previous question. In this case you are stating that an actor can be managed my many Theater Companies and A Theater Company and also manage many Actors. This is a many to many so if you created a link table in between those tables for every relastionship between the two you’d add a new row in the link table that only contains a theater Company id and an actor id. If an actor was managed by many theater companies then you’d add several rows to the link table each holding the same actor id but each row having a different theater company’s id.
Yes, you can have start_Location point directly to place. This means that that Start_Location attribute must be a Foreign Key (FK) pointing the theater company to the Primary Key (PK) of the related Place record.
By all means an actor can be born in a place, but just like above, you need a column in Actor, that is a FK to the Place Table’s PK. You could call this column Birth_Place and all it’d hold is the PK of the record in Place that relates to the actor’s birth place. This column would also need to be NOT NULL because all actor’s need a Birth_Place.
So far it seems like your diagram will work to solve this problem, yes. Just see question 1’s answer for that follow up addition.
You’re getting good at removing redundancies. Your diagram looks good. The only suggestion, I’d make is why do you have a play table and then 3 separate play type tables? Why not add them together in on Table called Play. It’d sit exactly where Play currently sits in your diagram and contain the same attributes it already does, but you also add the following:
a. Type – Would be a string that you could place “Drama”, “Comedy”, or “Tradegy” in so you’d know exactly what type of play it is. Also this would allow you to add future play types to the plays table and not have to add a whole new table to the DB.
b. Sub_Type – Would also be a string and hold the type that you currently have under the separate tables. They are all essentially the same attribute in each table and would just hold different type descriptors depending on the parent Type.
c. Main_Character – Would be a string that holds the main character, because in your three separate tables, you have main characters. You’re just calling them 3 separate things. (get the direction I’m going in here? )
d. Secondary_Character – Would be a string that holds the secondary character. You have a secondary character in your dramas and comedies, but non in your tradegies so in tradegy records this column would wind up being null. See what I did there? You now have one table where you used to have 4, and in that one table you can retrieve all the same information you had in those 4 separate tables. Hopefully that’ll make your life easier.
You can do whatever you like, but I’m assuming you mean by best practices and it would be generally considered best practice to separate this single attribute into it’s Simple attribute sub parts. I.E. make it a composed attribute.