I'm a bit confused at how to translate the Official entity in my ER diagram. I know for a 1:N relationship, the 1 side of the relationship becomes a foreign key in the N side of the relationship.
So for the relationship: Game - Head Officiated - Official, the primary key (game ID) should be a foreign key in the entity Official? Here's what I currently have and the entity Official doesn't look right.
Official (OfficialID, Fname, LName, Home City, GameID*??)
Game (GameID, Date, City, Head Official*)
My ER diagram
I'm beginning to doubt if my ER diagram is correct as well. Here's is a description of the database (I omitted the parts that are not relevant to the question:
For the officials, you must keep track of their first and last names (each will be 20 letters) and their official id (a 2 digit field) and their home city (15 letter field).
For games, you must keep track of the game id (2 digits), the date of the game and the city the game took place in (15 letters field).
Games are officiated by officials (refs). Every game has at least one official, but may have more. Every game has one official who acts as the head official (so every game will at least 2 officials, a regular one and a head one, HINT: keep track of both (officiates game and head officiates game) as 2 separate relationships). Some officials will be in our database who have not yet officiated any games.
EDIT: min,max notation messed me up. I get it now, sorry if I confused anyone.
Related
Im starting to learn how to work with database... i had a course in school about 5 years ago and i forgot almost everything. So im starting from 0. I have one project in my mind. A simple storage system for tires at a Vulcanizer(where you go and change tires when winter and summer comes).
So i have in mind 4 tables (client, car, tires, location). I have come up with an er diagram but i have problems with realtion between them. Can you please check if i am good so far? Or would you change something in my case?
More in picture
Looking at your ERD it mostly looks okay apart from the following:
You should have a foreign key location_id within your Tires table so that you know where the tire is stored. This would mean removing Tires_TiresID from your Location table. Unless i am misunderstood, the Client_ClientID is not-needed in the location table. This is because the location table should only hold information about the location its self i.e. address, contact details etc.
If I were you, i would do something along the lines of this:
I.E One Customer can have MANY vehicles.
One Vehicle can have MANY tire types.
One Location can have MANY inventory(tires).
One Tire can be in One Inventory line
I am having some trouble getting my head around cardinality in ER diagramming. I am linking an example I found to help me explain where I am getting confused.
http://www.postgresqltutorial.com/download/dvd-rental-er-diagram/#
Question 1:
The cardinality between Customer and Rental is 0:1. So that means a customer can take out zero or one rentals. I would have thought the customer would be able to take out 1 or many rentals (1:*) because a customer means that they are taking out a rental (can't be a customer if you are not spending any money) and that a customer could take out many rentals.
Question 2:
Also for the Staff to Payment relationship. Staff to Payment is 0:1 cardinality. I would have thought that a staff would make at least one payment because payments are necessary for the rental transaction. And then in reverse (one payment can be made by one and only payment): just to clarify this is because logically a payment is a transaction that only be made by one person at a time?
I agree with you. The same thing occurs on both sides of film_category, which I believe represents a many-to-many relationship based on the primary key. I think the diagram was drawn incorrectly.
Note that there's no such thing as 0:1 cardinality, but rather 0/1:1. Also, despite what the site and diagram says, the diagram is a table diagram and not an ER diagram. The notation used doesn't support or distinguish all the concepts from the Entity-Relationship model. Proper ER diagrams use Chen's notation or something equivalent.
I have done a lot of reading into multiplicities for ER diagrams, and I believe I have an understanding of what each requirement is, but as someone self studying with the internet and a textbook, it is hard to see where I have made mistakes.
Any feedback on this would be greatly appreciated.
Cinema - There are multiple cinema complexes with their name, location and contact number list.
Theatres - There are 4 in each cinema. Two types are available and each one is identified by a screen number.
Seats - Many seats in each theatre are determined by the row number, seat number and the seat type (comfort level).
Purchase - Tickets are to be purchased at the cinema complex. This will include screening date, time and seat number.
Members - Members are defined by their name and email.
Signup - Many members sign up with or without a discount at the cinema of their choice.
Per "The Entity-Relationship Model-Toward a Unified View of Data", Chen ERD lines between entity type boxes and relationship type diamonds denote participation of the entity type in the relationship type. There's no direction to the relationship type. There's an order to entity types in the a natural language (or wff) expression (or name) of the relationship type, but ERDs don't show that by an arrow. ("Has" is uninformative. You mean a kind of "Within", of which you have two, isSeatWithinTheatre & isTheatreWithinCinemaComplex.)
An arrow expresses "the existence dependency of one entity type on another".
Chen ERDs have one number (or range) per line. It gives "the number of entities in each entity set which is allowed in a relationship set".
PS Your ERD says a CinemaComplex has an associated Merchandise but presumably there should be a relationship CinemaComplexSellsMerchandise.
PPS Please represent your ERD in text in your question. Every box & diamond gets a table with PK, every box, oval & participant gets an attribute, every line gets a FK. Sadly, presentations of ERDs are typically vague about allowing relationship type attributes (rather than entities) as parts of PKs.
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.
I am building a music streaming site, where users will be able to purchase and stream mp3's. I have a subset entity diagram which can be described as follows:
I want to normalise the data to 3NF. How many tables would I need? obviously I want to avoid including partial dependancies, which would require more tables than just album, artist, songs - but I'm not sure what else to add? Any thoughts from experience?
Well, you've done the ER level. You need to identify Keys and Attributes before you can work out Functional Dependencies. There is a fair amount of work to do before you get to 3NF. Eg. Song Titles are duplicated.
Also, there are questions:
is the site selling Albums, Songs, or both ? (I've modelled both)
if both, how do you track a sale or download ?
do you care about the same Song title recorded by different Artists ?
Anyway, here is a resolved ▶Entity Relation Diagram◀, at least for the info provided. It is closer to 5NF than 3NF, but I cannot declare it as such, because it is not complete.
Readers who are unfamiliar with the Standard for Modelling Relational Databases may find ▶IDEF1X Notational◀ useful.
It uses a simple Supertype-Subtype structure, the Principle of Orthogonal Design. The Item that is sold ie either an Album xor a Song.
Feel free to ask clarifying questions.
You will need 4 tables: Artists, Songs, Albums, and AlbumSongs.
The last one is required since the exact same song (=same edit/version...) could be included in several albums, so you have there a m-to-m relationship.
I agree with iDevelop but with 1 extra table. Here is how I would model it.
Tables: Artist, Song, Album, AlbumSongMap, SingleInfo
If the song was a released as a single on a different date, you can get that from SingleInfo. The single may have been released with some cover art that is different from the album art. You would store the singles art in SingleInfo. MAYBE a song can be released as a single multiple times, with new cover art or something so it could possibly be a 1-many relation. Otherwise it is 1-1.
If you can join Song with SingleInfo that means it was released as a single. If you can join Song with Album (using the map) then you will find all the album's it was released under.
A digital enhancement to an old song is a new song. (or at least a different binary). You may want to further normalize Song to allow storage of digital enhancements without duplicating songName, etc.
When you switch over from ER modeling to relational modeling (tables), you need one table for each entity. You also need a table for some relationships.
In the diagram you've given us, both relationships are many to one. Many to one relationships do not require a table. You can get away with adding foreign keys to entity tables. Therefore the answer to your question is 3 tables: Artists, Albums and Songs.
However, I question your ER diagram. It seems to me that the "contains" relationship is really many to many. An album clearly contains many songs. But a given song can appear on more than one album. So there should be an arrowhead on the line that connects "contains" to "album".
If you accept this revision to your ER model, then the number of tables increases to 4: Artists, Albums, Songs, and Contains.
A similar argument might be made for Artist and Song. If two artists collaborate on a single song, (e.g. Dolly Parton and Kenny Rogers singing "Islands in the Stream" together,
then you might want to model "produces" as a many to many relationship. Now you need 5 tables: Artists, Albums, Songs, Contains and Produces.
Artists, Albums, and Songs are going to require a PK that identifies the corresponding entity. Entity integrity demands that the correspondence bewteen entity instances and table rows be one-to-one.
The Contains and Produces tables can be built without a separate Id attibute. You will need a pair of FKs in each of these tables, and you can declare a compound PK for each table consisting of the two FKs.
Referential integrity demands that you enforce the validity of FK references, either in your programs or by declaring a references constraint in the DB. I strongly prefer declaring the constraint in the DB.