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.
Related
The following problem comes from: https://cs.senecac.on.ca/~dbs201/pages/Normalization_Practice.htm (Exercise 3)
The unnormalized table appears like this:
To comply with First Normal Form, all repeating groups must be dealt with. In this case, multiple products could appear on a single order, so it must be given its own entity and related back to the original table:
These tables are also in Second Normal Form, because in all of the tables, each non-key attribute is dependent on the primary key in it's table.
Finally, to bring it to Third Normal Form, Customer must be given its own entity and related back to the original Order entity:
Have I properly normalized the original table into Third Normal Form? If not, please provide feedback explaining what I've done wrong.
Store some Customer's Primary details in Order Table which are available on Bill, because once customer details is changed then Bill is differ then original.
Same for Product, Store Product price in Product_Order table, because once Product price changed Bill will change.
I edited and remade the ERD. I have a few more questions.
I included participation constraints(between trainee and tutor), cardinality constraints(M means many), weak entities (double line rectangles), weak relationships(double line diamonds), composed attributes, derived attributes (white space with lines circle), and primary keys.
Questions:
Apparently to reduce redundant attributes I should only keep primary keys and descriptive attributes and the other attributes I will remove for simplicity reasons. Which attributes would be redundant in this case? I am thinking start_date, end_date, phone number, and address but that depends on the entity set right? For example the attribute address would be removed from Trainee because we don't really need it?
For the part: "For each trainee we like to store (if any) also previous companies (employers) where they worked, periods of employment: start date and end date."
Isn't "periods of employment: start date, end date" a composed attribute? because the dates are shown with the symbol ":" Also I believe I didn't make an attribute for "where they worked" which is location?
Also how is it possible to show previous companies (employers) when we already have an attribute employers and different start date? Because if you look at the Question Information it states start_date for employer twice and the second time it says start_date and end_date.
I labeled many attributes as primary keys but how am I able to distinguish from derived attribute, primary key, and which attribute would be redundant?
Is there a multivalued attribute in this ERD? Would salary and job held be a multivalued attribute because a employer has many salaries and jobs.
I believe I did the participation constraints (there is one) and cardinality constraints correctly. But there are sentences where for example "An instructor teaches at least a course. Each course is taught by only one instructor"; how can I write the cardinality constraint for this when I don't have a relationship between course and instructor?
Do my relationship names make sense because all I see is "has" maybe I am not correctly naming the actions of the relationships? Also I believe schedules depend on the actual entity so they are weak entities.... so does that make course entity set also a weak entity (I did not label it as weak here)?
For the company address I put a composed attribute, street num, street address, city... would that be correct? Also would street num and street address be primary keys?
Also I added the final mark attribute to courses and course_schedule is this in the right entity set? The statement for this attribute is "Each trainee identified by: unique code, social security number, name, address, a unique telephone number, the courses attended and the final mark for each course."
For this part: "We store in the database all classrooms available on the site" do i make a composed attribute that contains site information?
Question Information:
A trainee may be self-employed or employee in a company
Each trainee identified by:
unique code, social security number, name, address, a unique
telephone number, the courses attended and the final mark for each course.
If the trainee is an employee in a company: store the current company (employer), start date.
For each trainee we like to store (if any) also previous companies (employers) where they worked, periods of employment: start date and end date.
If a trainee is self-employed: store the area of expertise, and title.
For a trainee that works for a company: we store the salary and job
For each company (employer): name (unique), the address, a unique telephone number.
We store in the database all known companies in the
city.
We need also to represent the courses that each trainee is attending.
Each course has a unique code and a title.
For each course we have to store: the classrooms, dates, and times (start time, and duration in minutes) the course is held.
A classroom is characterized by a building name and a room number and the maximum places’ number.
A course is given in at least a classroom, and may be scheduled in many classrooms.
We store in the database all classrooms
available on the site.
We store in the database all courses given at least once in the company.
For each instructor we will store: the social security number, name, and birth date.
An instructor teaches at least a course.
Each course is taught by only one instructor.
All the instructors’ telephone numbers must also be stored (each instructor has at least a telephone number).
A trainee can be a tutor for one or many trainees for a specific
period of time (start date and end date).
For a trainee it is not mandatory to be a tutor, but it is mandatory to have a tutor
The attribute ‘Code’ will be your PK because it’s only use seems to be that of a Unique Identifier.
The relationship ‘is’ will work but having a reference to two tables like that can get messy. Also you have the reference to "Employers" in the Trainee table which is not good practice. They should really be combined. See my helpful hints section to see how to clean that up.
Company looks like the complete table of Companies in the area as your details suggest. This would mean table is fairly static and used as a reference in your other tables. This means that the attribute ‘employer’ in Employed would simply be a Foreign Key reference to the PK of a specific company in Company. You should draw a relationship between those two.
It seems as though when an employee is ‘employed’ they are either an Employee of a company or self-employed.
The address field in Company will be a unique address your current city, yes, as the question states the table is a complete list of companies in the city. However because this is a unique attribute you must have specifics like street address because simply adding the city name will mean all companies will have the same address which is forbidden in an unique field.
Some other helpful hints:
Stay away from adding fields with plurals on them to your diagram. When you have a plural field it often means you need a separate table with a Foreign Key reference to that table. For example in your Table Trainee, you have ‘Employers’. That should be a Employer table with a foreign key reference to the Trainee Code attribute. In the Employer Table you can combine the Self-employed and Employed tables so that there is a single reference from Trainee to Employer.
ERD Link http://www.imagesup.net/?di=1014217878605. Here's a quick ERD I created for you. Note the use of linker tables to prevent Many to Many relationships in the table. It's important to note there are several ways to solve this schema problem but this is just as I saw your problem laid out. The design is intended to help with normalization of the db. That is prevent redundant data in the DB. Hope this helps. Let me know if you need more clarification on the design I provided. It should be fairly self explanatory when comparing your design parameters to it.
Follow Up Questions:
If you are looking to reduce attributes that might be arbitrary perhaps phone_number and address may be ones to eliminate, but start and end dates are good for sorting and archival reasons when determining whether an entry is current or a past record.
Yes, periods_of_employment does not need to be stored as you can derive that information with start and end dates. Where they worked I believe is just meant to say previous employers, so no location but instead it’s meant that you should be able to get a list all the employers the trainee has had. You can get that with the current schema if you query the employer table for all records where trainee code equals requested trainee and sort by start date. The reason it states start_date twice is to let you know that for all ‘previous’ employers the record will have a start and end date. Hence the previous. However, for current employers the employment hasn't ended which means there will be no end_date so it will null. That’s what the problem was stating in my opinion.
To keep it simple PK’s are unique values used to reference a record within another table. Redundant values are values that you essentially don’t need in a table because the same value can be derived by querying another table. In this case most of your attributes are fine except for Final_Mark in the Course table. This is redundant because Course_Schedule will store the Final_Mark that was received. The Course table is meant to simply hold a list of all potential courses to be referenced by Course_Schedule.
There is no multivalued attributes in this design because that is bad practice Job and salary are singular and if and job or salary changes you would add a new record to the employer table not add to that column. Multivalued attributes make querying a db difficult and I would advise against it. That’s why I mentioned earlier to abstract all attributes with plurals into their own tables and use a foreign key reference.
You essentially do have that written here because Course_Schedule is a linker table meaning that it is meant to simplify relationships between tables so you don’t have many to many relationships.
All your relationships look right to me. Also since the schedules are linker tables and cannot exist without the supporting tables you could consider them weak entities. Course in this schema is a defined list of all courses available so can be independent of any other table. This by definition is not a weak entity. When creating this db you’d probably fill in the course table and it probably wouldn’t change after that, except rarely when adding or removing an available course option.
Yes, you can make address a composite attribute, and that would be right in your diagram. To be clear with your use of Primary key, just because an attribute is unique doesn’t make it a primary key. A table can have one and only one primary key so you must pick a column that you are certain will not be repeated. In this example you may think street number might be unique but what if one company leaves an address and another company moves into that spot. That would break that tables primary key. Typically a company name is licensed in a city or state so cannot be repeated. That would be a better choice for your primary key. You can also make composite primary keys, but that is a more advanced topic that I would recommend reading about at a later date.
Take final_mark out of courses. That’s table will contain rows of only courses, those courses won’t be linked to any trainee except by course_schedule table. The Final_Mark should only be in that table. If you add final_mark to Course table then, if you have 10 trainees in a course, You’d have 10 duplicate rows in the course table with only differing final_marks. Instead only hold the course_code and title that way you can assign different instructors, trainees and classrooms using the linker tables.
No composite attribute is needed using this schema. You have a Classroom table that will hold all available classrooms and their relevant information. You then use the Classroom_Schedule linker table to assign a given Classroom to a Course_Schedule. No attributes of Classroom can be broken down to simpler attributes.
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 try to design database which contains data about street parking. Parking have gps coordinates, time restriction by day, day of week rules (some days are permitted, other restricted), free or paid status. In the end, I need to do some queries that can specify parking by criteria.
For first overdraw I try to do something like this:
Pakring
-------
parkingId
Lat
Long
Days (1234567)
Time -- already here comes trouble
But it`s not normalized and quickly overflow database. How to design data in the best way?
Update For now I have two approaches
The first one is:
I try to use restrictions tables with many-to-many links.(This is example for days and months). But queries will be complicated and I don`t now how to link time with day.
The second approach is:
Using one restricted table with Type field, that will have priority. But this solution also not normalized.
Just to be clear what data I have.
PakingId Coords String Description(NO PARKING11:30AM TO 1PM THURS)
And I want to show user where he can find street parking by area, time and day.
Thanks to all for your help and time.
This seems like a difficult task. Just a few thoughts.
Are you only concerned with street parking? Parking houses have multiple floors so GPS coordinates won't work unless you stay on the streets.
What is the accuracy of the coordinates? Would it be easier to identify each parking space individually by some other standard. Like unique identifiers of the painted parking squares. (But what happens if people don't park into squares? Or the GPS coordinates accuraycy fails/is not exact enough because of illegal parking? Do you intend to keep records of the parking tickets too?)
Some thought for the tables or information you need to take into account:
time: opening hours, days
price: maybe a different price for different time intervals?
exceptions: holidays, maintenance (maybe not so important, you could just make parking space status active/inactive)
parking slot: id (GPS/random id), status
Three or four tables above could be linked by an intermediate table which reveals the properties of a parking space for every possible parking time (like a prototype for all possible combinations). That information could be linked into another table where you keep records of a actual parking events (so you can for example keep records of people who have or have not paid their bills if you need to).
There are lots of stuff that affect your implementation so you really need to list all the rules of the parking space (and event?). Database structure can be done (and redone) later after you have an understanding of the properties of the events you need to keep records of. And thats the key to everything: understanding what you need to do so you can design and create the implementation. If the implementation (application) doesn't work change the implementation. If the design is faulty redesign. If you don't undestand the whole process (what you really need), everything you do is bound to fail. (Unless you are incredibly lucky but I wouldn't count on luck...)
Try using two tables with an intersection entity between them.
Table parking will have parking_id, lat and long columns. Table Restrictions will have all the type of restrictions that you have in your scenario with something like restriction_id, restriction_day, restriction_time and restriction_status and maybe restriction_type.
Then you can link the two tables with foreign key constraints in the intersection entity.
Example parking_id has restriction_id.
This way a parking can have more than one restriction and a restriction can be applied to more than one parking.
As you seem to have heard of normalization, and following the comment from Damien, you should use different tables to represent different things.
You should then think about how to link those tables together, and in the process define the type of relationship between the 2. Could be one-to-one (this one is the one where you could be tempted to put everything in the same table, but a simple foreign key in a linked table is cleaner), one-to-many (this is where the trouble would begin if you put everything in one table, cause now there will be several lines in the linked table with the same foreign key, and if everything was in the same table, you'd have to myltiply the fields in that table), or many to many (where you would need to add a table only to make the link between 2 other tables, thus with 2 foreign key fields pointing to records in both tables).
For example, in your case, a Parking table could hold the parking name, coordinates, etc.
A second table TimeTable could hold the opening days/time for each parking, with a foreign key to the parkingId (making it a one-to-many rlationship, 1 parking can have many opening frames). The fields of this table could for example be DayOfWeek (number indicating the day), openingTime, closingTime. This would allow you to define several timeframes on the same day, or a single one (if it's always open for example), giving in this case 7 records in this table for this parking (=> one-to-many relationship).
You could then imagine a 3rd table Price where you put data concerning the price of that parking (probably a one-to-many too, with records for hourly rates/long stay/..., and so on depending on the needs and the different "objects" you would need to represent.
Please note these are only rough examples. Database design can sometimes be very tricky and that's a matter I'm not specialist in, but I think these advises can help you go further and come back with another question if you get stuck.
Good luck !
I just joined this site and this is my first question , I hope my question it's according to the StackOverflow question policy.
I'm designing a DB for Phone book which has the following abilities
Contact have 2 types (Company or Person)->ContactType
And I want each contact to have as many Emails, Phones Numbers, and Addresses as it wants.
And I want to specify which Person works in which Company , so I can show not only a Company Contact detail but also list of its employees and their jobs in that Company and their Contacts (CoEmpJob table)
I have designed a db diagram which is shown in the link below, is it well structured or can I achieve what I want in some better way?
Thanks in advance.
My Phone Book Design
As the design stands, you're missing a few things, such as a Companies table and a ContactTypes table. There seems to be no foreign key in the CoEmpJob table linking to the Contacts table.
In the Phones table, I personally wouldn't use a prefix field (unless you wish to display contacts by phone prefix), in which case every phone number is guaranteed to be unique, in which case the PhoneNum field becomes the primary key and the PhoneID field is unnecessary - but you might have the case in which husband and wife are in the same database; whilst they almost certainly have different mobile numbers, they almost certainly share the same home phone number! In this case, your design is correct.
I don't know how many people have more than one address (I would think very few, if at all) which means that the fields of the Address table could be moved into the Contacts table.
(Added)
As regards the companies, if you want to specify which Person works in which Company, then you will need a companies table (missing) and a join table (CoEmpJob). In the real world, this design would also require more tables - a join table can show which contacts are connected to which companies and what their current jobs are, but people change jobs (and companies) and so such a design would not store any history. Also, it is customary to link people (employees) to a department - and it is possible that one person can be connected to more than one department at a time, meaning that you will need another join table. This can get very complicated - it depends on what you want.
Your comment suggests that you want to store company data in the contacts table - this is a very bad idea; they should be kept separate.