there is a problem of designing a movie database. A movie can only have one director and many actors and many writers, also the actors should be stored in a CAST table which shows the role of each actor in the movie and the STAR ACTOR should be identified.
how should i implement this? any help
here is the ERD
I would have a separate table for each of writer, director, and actor. It seems as though the data you'd like to store for actors (i.e. "Star Actor") wouldn't ever apply to a director or a writer.
OR
Make an actors table, and a separate "crew" table, which could include both directors and writers. A column in the crew table could be "profession" or something like that, which would be a foreign key to a "profession" table.
So I'd say that at minimum you'd want a separate table for the actors.
Related
I'm working on a database project about music and albums in MySQL, where i make a list over some popular artists, their most sold album, and the songs contained within them. But i suddenly got really uncertain of what to do when it comes to filling in the name of the songs for each album. Should i make an individual table for each list of songs, or should all the songs (about 50 of them in total from all the albums) from all the different artists (5 different artists) be filled inn in the same table (i'm eventually gonna export the data and connect it to a PHP folder
Hope the question was clear
All the songs should be in one "Songs" table. Then you create a column "Album ID" in that table which is a foreign key back to the ID column in the albums table. This is how you know which song belongs to which album. (And of course you have the same kind of relationship between "album" and "artist".)
This is called a "one-to-many" relationship and is one of the basic principles of relational database design.
If you ever find yourself creating multiple tables to represent the same kind of data item, you know you've gone wrong.
N.B. If you want to support the idea that the same song (or track probably, to be more accurate, since many different recordings of a song could potentially be made) can be included on multiple albums, then you'll need to implement a "many-to-many" relationship where you have an extra table in between "albums" and "songs" which holds Album ID and Song ID. Each would be a foreign key back to the Albums and Songs tables, respectively. And to ensure no duplication, both fields would be specified as a Compound Primary Key. That way you can list the same Song ID in that table many times against different albums. Same again if you want to have that flexibility in the relationship between "artists" and "albums".
This might be a good time to take a break and study relational database design and data normalisation concepts in some more detail, then you can start to see these patterns for yourself and make the right decision in your schema designs.
Similarly to this question about databases for playlists you should also use one table for the albums and one table for the songs.
Additionally you might also need a table for artists, etc.
I'm trying to create a database schema using information pulled from the themoviedb api.
I thought I was doing ok until I went to add in the television series, then I got really confused.
The TMDb API seems to treat television series and movies as completely separate things. It further divides television listings into series, seasons, and episodes.
For example there is a separate cast listing for television seasons (season regulars) and individual episodes (guest cast). I have no idea how to reflect all this in the database.
I've tried my best to model everything below, but I think there's something wrong somewhere. Please ignore the datatypes.
Role can be either writer, director, or actor.
http://imgur.com/a/1WKQB
Hi user2146821,
Your database design looks good, with the exception of how to display the relations between regular cast and guest cast members, as you've expressed.
Currently, you are approaching the scenario by having a singular join table between Movie, TV Seasons, TV Episodes and Person. This creates a table for which you cannot have either a singular primary key nor a correct composite primary key, as you will have nulls for any given record.
In the linked image above, you can see another way of handling this relationship - you create three join tables, each with Person on one side and a corresponding table on the other (either Movie, TV Season or TV Episode). This eliminates nulls from the join tables, allows for composite primary keys to be formed in the joins tables and structures the database in a more meaningful way.
I'm creating this little Access DB, for the HR department to store all data related to all the training sessions that the company organizes for all the employees.
So, I have a Training Session table with information like date, subject, place, observations, trainer, etc, and the unique ID number.
Then there's the Personnel table, with employer ID (which is also the unique table number), names and working department.
So, after that I need another table that keeps a record of all the attendants of each training session. And here's the question, should I use a table for that in the first place? Does it have to be one table for each training session to store the attendants?
I've used excel for quite some time now, but I'm very new to Access and databases (even small ones like this). Any information will be highly appreciated.
Thanks in advance!
It should be one table for persons, one table for trainings, and one for participation/attendance, to minimize (or best: avoid) repetition. Your tables should use primary and foreign keys, so that there are one-to-many relationships between trainings and attendances as well as people and attendances (the attendances table would then have a column referring to the person who attended, and another column referring to the training session).
Google "database normalization" for more detail and variations of that principle (https://en.wikipedia.org/wiki/Database_normalization).
I am creating a windows forms application that must control the entry and exit of people in an office building. These people may be visitors or employees, and everybody must use an access card at the building entrance. A card will be programmed temporarily when the person is a visitor, and the employees should use their own cards. My doubt is about my database. Is there a way to do this nicely? The cards (no matter if it is an employee or visitor ) has a strong key to the ratchet can identify it wich comes from the manufacturer of turnstiles and I can't change it. So, my structure is:
In my database, I have a table where I keep the cards. When someone try to get inside the building, the turnstile sends to my system the date and time of access and the card code. Now I do not know how to separate the employees and visitors. Should I have a separated flow table to employees and visitors? For the employees flow table, I get the employees card from the card table using the same ID. In the visitor flow table, I need to know who is the visitor using the temporary card (the key to the temporary card never changes, so I can not rely on me only in the key). Or should I only have a flow table with a Visitor_ID and Worker_ID column , one of which will always be null (so I know if it was an employee or a visitor by the field with a value).
Can anyone tell me which of the two is more applicable and why?
Employees and visitors are both people. Specifically people that may (or may not) have an access card assigned to them.
I would have one People table that has a foreign key relationship to the AccessCard table. If you only care about whether the person is an employee or visitor, but the information you store is otherwise identical, a boolean column is fine. If your system stores additional information for employees and/or visitors, create an Employees and Visitors table, and have a foreign key relationship from People to each of those.
I would create single table to store both employee and visitor then add an extra column for Type(E, V).
I have a problem with a many-to-many relation in my tables, which is between an employee and instructor who work in a training centre. I cannot find the link between them, and I don't know how to get it. The employee fields are:
employee no.
employee name
company name
department job title
business area
mobile number
ext
ranking
The Instructors fields are
instructor name
institute
mobile number
email address
fees
in a many-to-many relationship the relationships will be in a 3rd table, something like
table EmployeeInstructor
EmployeeID
InstructorID
to find all the employees for a specific instructor, you'd use a join against all three tables.
Or more likely there will be classes involved --
Employee takes Class
Instructor teaches Class
so you'll have and EmployeeClass table,
an InstructorClass table,
and join through them. And Class needs to be unique, or else you'll need
Class is taught in Quarter on ClassSchedule
and end up joining EmplyeeClassSchedule to InstructorClassSchedule.
This ends up being one of your more interesting relational designs pretty quickly. If you google for "Terry Halpin" and "Object Role Modeling", this is used as an illustrative situation in the tutorial.
First of all, you will need a unique key in both tables. The employee number may work for the employee table, but you will need another for the instructor table. Personally, I tend to use auto incrementing identity fields called ID in my tables. This is the primary key.
Second, create a new table, InstructorEmployee. This table has two columns, InstructorID and EmployeeID. Both fields should be indexed. Now you can create an association between any Employee and any Instructor by creating a record which contains the two IDs.