There are 3 entities:
vehicle_model
vehicle
extra_options (such as open top, leather seats, etc..)
Vehicle model can have a subset of the extra options.
Vehicle can have a subset of it's model extras.
I've been trying hours to figure out how to represent this as er diagram, but without success. I Thought about ternary relationship ,and although I don't understand it completely I think this isn't the way.
I thought about creating another 2 entities, model_ext & vehicle_ext ,so that vehicle_ext would be connected to model_ext but this isn't a good design.
This is my first er diagram design. I'm really lost (read er-diagram chapter in "Silberschatz, Database System Concepts" three times already) so any idea would be appreciated.
did you try adding a new table say 'vehicle_vehicle_model_extra_options_map'? (you can name this table to any thing short, but for better explanation i use __map as a standard way for defining the map tables.)
note those two null able foreign key columns in this table.
Basically, vehicle has one to many relation to extra_options, and vehicle_model has one to many relation to extra_options table, therefore the new table was added.
updated:
Related
I'm having a hard time modeling a certain scenario without having to appeal to more than one request.
Think about a People table, each Person can be related to eachother n times, and this relationship has a description.
Consider the following modelling :
As you can see, I have two People, and person_0001 is child of person_0002.
Now, in this case, if I want to get all relationships that person_0001 has, it's easy, I just query :
GET WHERE PK = "person_0001" AND SK.BEGINS_WITH("rel")
But, since it is bidirectional, how can I get the relationships person_0002 has?
I could use a GSI that inverts the keys, so with one request I can simply query both tables at once.
But real problem comes when I need to update/delete, How can I delete/update all relationships person_0002 has with only one request? I can only read from GSIs.
It's a big difficulty I have in general, what do I do when I need to do a delete/update/write on a GSI?
I'm trying to figure out the best way to link a dimension to a fact table and having some trouble finding an example in the documentation. All of my data sources are csv files and I have the following 2 data tables:
Areas table with columns: Area,DateTime,Cost (Area,DateTime are unique)
Company table with columns: CompanyID,Area (CompanyID is unique and represents a dimension)
I would like to link the Company Dimension to the Cost measure from the Areas table. However, it seems that I can only link the Company dimension to the Areas measure group through the dimension key, which is CompanyID. Is there a way around this or do I need to add a CompanyID column to my Areas csv file prior to loading.
thanks
I'm not really sure what you want to achieve but it looks as you could use a many-to-many cube to create a link from Area to Company (even though it might be a one-to-on relation).
1) Create a many-to-many cube using your Company table (Advanced/Many-to-Many)
2) Bind the Company dimension in the facts, Area table, using the defined many-to-many relation.
Some documentation here (the first image is wrong).
hope it helps.
Quick Summary: I'm building an ERD diagram and got lost in connecting two tables.
Introduction:
I'm building an ERD diagram for my project. Idea is pretty straight forward: I can type information about the company and it will be saved in the database. Later, I can see the list of submitted companies, as a list. As of now, I've information on the "paper", which I've implemented into my ERD diagram, so that later I can tell database, what exactly must be saved and where.
I have a primary table "Company_Info" which stores all the information about the company in the database. Using common sense (or not :)) I've created "Foreign Tables" that would store information about the company: "Gallery Images", "Opening_hours", etc. This way I believe, the database would more or less clear and readable by others.
ERD Diagram with the Description of all relationships
Problem Statement
The idea was to create a simple gallery for the company, so that they can upload their Product-pictures. If it's possible I would like to talk about the relationship between the Gallery and the Company tables. The way I see it, I think it should be like this:
One company can have 0,1,2 or many images. (Gallery_Images Table)
Images must be assigned to only 1 company. (Company_Info Table)
The relationship is one mandatory to many optional. (Many images & one company)
Question: I think the relationship between the Gallery_Table and Company_Info table will not work. Reason: Wrong relationship. I'm confused about the connection between those two tables.
I have made a connection via company PK & FK. This way, I think, the database would know what images belong to that specific company.
Confusion is with gallery_id in Gallery_Images table. Shouldn't it be connected with the company_info table too?
Image(BLOB) is a repeating group in Gallery_Images. This is not a problem if your purpose is to draw a diagram of an ER model.
If your purpose is to draw a diagram of a relational model, then the repeating group is a departure from First Normal Form. Relational schemas that depart from 1NF are generally subject to terrible problems, both with regard to performance and with regard to data management itself.
I don't see the Gallery table in your diagram. Did I miss something?
While using Graph Databases(my case Neo4j), we can represent the same information many ways. Making each entity a Node and connecting all entities through relationships or just adding the entities to attribute list of a Node.diff
Following are two different representations of the same data.
Overall, which mechanism is suitable in which conditions?
My use case involves traversing the Database from different nodes until 4 depths and examining the information through connected nodes or attributes (based on which approach it is).
One query of interest may be, "Who are the friends of John who went to Stanford?"
What is the difference in terms of Storage, computations
Normally,
properties are loaded lazily, and are more expensive to hold in cache, especially strings. Nodes and Relationships are most effective for traversal, especially since the relationships types are stored together with the relatoinship records and thus don't trigger property loads when used in traversals.
Also, a balanced graph (that is, not many dense nodes with over say 10K relationships) is most effective to traverse.
I would try to model most of the reoccurring proeprties as nodes connecting to the entities, thus using the graph itself to index on these values, instead of having to revert to filter on property values or index the property with an expensive index lookup.
The first one is much better since you're querying on entities such as Stanford- and that entity is related to many person nodes. My opinion that modeling as nodes is more intuitive and easier to query on. "Find all persons who went to Stanford" would not be very easy to do in your second model as you don't have a place to start traversing from.
I'd use attributes mainly to describe the node/entity use them to filter results from the query e.g. Who are friends of John who went to Stanford in the year 2010. In this case, the year attribute would just be used to trim the results. Depends on your use case- if year is really important and drives a lot of queries or is used to represent a timeline, you could even model the year as a node attached to Stanford.
Am making a cube in SQL Server Analysis Services 2005 and have a question about many to many relationships.
I have a many to many relationship between two entities that contains an additional descriptive column as part of the relationship.
I understand that I may need to a bridge table to model the relationship but I am not sure where to store the additional column - in the bridge table or elsewhere?
Many To Many relationsip in SSAS can be implemented via an intermediate fact table that contains both dimension key that subject to the relation.
For example; If you have a cube that has a book-sales-fact table and you want to aggregate total sales by author (which may have many books and a book may be written by many authors) you should also have a author-book intermediate fact table (just like in relational database world). In this bridge table, you should have both dimension keys (Author and Book) plus some measure related to the current book and author such as wages paid to the author to write the book (or chapters).
As a result, if your additional column is kind of a measure you should add that column to the intermediate fact table.