I have a table named people
Each person can be a client, a manager, an accountant, or any combination of the three.
Also each of them have special table columns, besides the ones in the people table.
What I'm doing now is using a person_id in each of the tables... but I think it would be much simpler to just used the same table, and a different model for each one, so I can manage them separately.
Should I do that?
You don't have a nice inheritance hierarchy so I don't think STI applies. For example, how would you represent a person that was both a manager and an accountant in terms of (single) inheritance?
If a person could only have one of the three roles then maybe STI would make sense; but even then implementing roles using inheritance should be setting off warning bells in your head, you should know that one person will end up needing multiple roles sooner or later (and it will probably become a critical necessity immediately after delivery).
Related
Quick question about an ER/EER Diagram.
I have made this Entity Relationship Diagram, but I have been told, that there is something wrong with it by a friend. Is there something wrong with it?
The ER diagram is a design of a Library Management System, where a member can borrow 5 books at a time. The rest of the functionality of the system is how a normal library functions.
Library Management System EER
i don't understand the utility of the relationship between the librarian and the card and i don't understand why the books are splitted in two entities.
I would do 3 entities:
-member
-card
-book
every member has one card, every card is of one member;
every member can take many books, every book can be taken by many members,
the relation between member and book create another table in the logic schema: loans. before inserting a new loan you can check if the member has alredy 5 active loans (by checking the attribute active in the loans table).
Your given context is incomplete for me. I do not see the whole description of your problem/situation, so I will answer based on assumptions, and the experience I had during my life. So let's see...
The tino user questioned the existence of two entities, title and volume, which is something important. Let me explain this for a moment, which will eliminate this as an error. Previously (a time ago) we had video rental stores (I don't know if this the right name where you live, english is not my native language). Remember? We used to go there to rent VHS tapes to watch at home.
What we rented were not films, but more copies/midia of them. A film will always have the same actor, director, title, etc., but a copy could have different attributes/properties, like the year that the media was manufactured, the available languages, the expiration year, among other things. So we had distinctly two different things.
But despite this, we have to consider whether there is a need to create two entities for persistence. We have to remember if we need to persist this information. If a copy/midia has no attributes, then it's entity should not exist, and what a user would rent really would be the movies titles.
In your case, the relationship between volume and title, I belive, is really expressing this discrepancy.
Let's talk about the relationship between librarian and title. What a librarian manages? Does It manages the titles that never change and are abstract things, or the physical objects present in the library? :)
Finally, let's talk about the borrows relationship. When we break down 1-N (or N-1) relationships, we always pass the primary key from the 1 side to the N side, solving the relationship to the formation of the Physical Model in a Entity-Relationship Diagram.
Despite this relationship here is a 0-5, to decompose it, we will not have exactly a 0-5 relationship. We would have in anyway to pass the primary key from the two sides to the table formed by this relationship. Therefore, here we have initially a N-N relationship between member and volume.
N-N relationships allow optional relations between entities. This means we can have the zero side cardinality here. To limit the number of books that can be rented, you need to implement a restriction/constraint with SQL, or with any procedural language in your database. In this case, you can implement a before insert trigger. This trigger has a duty to verify this restriction to allow or denny the completion of the operation as a whole.
Let it be clear that I'm not saying you should remove this notation. Your Conceptual Model should express it. But when you are decomposing, you have to remember that. I think you should just correct it.
Remember one important rule: Relations that have attributes/properties (the attributes/properties) can only exist in N-N relationships. If you have to put attributes/properties in a 1-N (or a N-1) relation, they (the attributes/properties) will always be on the N side. In summary, there are no N-1 (or 1-N) relationships with attributes in the relation. Only N-N relations can have attributes/properties. So be careful with this.
Any questions or clarification, please comment and I will answer.
I see no reason to distinguish member and card. Volume and Librarian don't have primary keys. Are they supposed to be weak entities? That doesn't make sense for Librarian and Volume needs an identifier to distinguish different copies.
I have some questions need to be answered. The requirement is to build a database for university entrance system:
"Applicant may apply to 5 university, each university may or may not interview the applicant, then, make an offer to the applicant. The offer may or may not be conditional (conditional/uncondtional), if the offer is conditional, the conditions are stored. The applicant need to choose which conditional offers he/she wishes to accept, up to maximum of 3. If any of the conditions is met when end of the year, the offer becomes unconditional, then, applicant may accept that one."
There are some notable points:
The course work requires using some enhanced ER features such as supertype/subtype.
Regardless the offer is conditional or unconditional, the applicant can accept the offer. Am I right?
In my ERDs, the APPLICATION entity is a weak entity, using a surrogate key, and UNIQUE_CONSTRAINT on University_ID and Applicant_ID.
In my ERD (on working), there are 2 versions. The ERD_1 is a suggestion of my friends. But I think, my work on ERD_2 is more accurate. I have questions:
Am I correct when use a surrogate in the APPLICATION entity? OR using composite of University_ID and Applicant_ID is a primary key?
Could APPLICATION entity be an associate entity? If it is, it could have some subtypes?
In ERD_2, how to show the ACCEPT relationship between APPLICANT and OFFER entity? AND how to show the MAKE relationship between UNIVERSITY and OFFER?
ERD_1
ERD_2
I would appreciate any help.
I can think of no reason why a weak entity could not be analyzed into subtypes (aka subclasses aka specializations). However, your two ERDs suggest that your analysis of your case is not one of specializations. In particular, in your first ERD, you use the word "has" to describe the relationship between an application and an interview or an offer.
"Has-a" relationships are typically not generalization-specialization relationships. "Is-a" relationships typically are. Example: An auto is a vehicle and a truck is a vehicle.
There is an entirely different issue here when it comes to what tables, columns, and constraints you will use to implement your model. That's a design issue rather than an analysis issue.
I don't understand your case well enough to agree or disagree with your analysis of your case.
I'm interested in the new firebase.util package that allows you to join data (paths) and how I might be able to continue modeling with UML as I have become accustomed to over many years. I can see how easy it might be to make one-to-many relationships in this way. And because firebase is hierachical, component relationships are just very natural.
Aggregate relationships can be duck'd as we're all accustomed to this in javascript - enforcing aggregate relationship doesn't seem to me to be a barrier to modeling successful projects using firebase...
My question is if anyone has experimented | had success with | can show examples of how it might be possible to represent many-to-many relationships, perhaps by joining the join paths themselves.
If I don't get much interest in the question I may post my own trial-error results...
Thanks
I have tried to use composite key. For example, user can be member of many rooms. We need two queries: List of room members, and list of user's rooms. So we can have only one collection rooms-users, where key is built like this:
id = [roomId, userId].join()
The truth is, I'm not sure whether it is a good pattern. It seems it can prevent security rules settings https://stackoverflow.com/a/17431390/233902 and maybe even have performance implications.
So maybe two or even more collections are required. Two for many to many, third for relation metadata. As I'm thinking about, collections should be optimized for queries, so composite key is anti-pattern for Firebase.
I'm new to database design and have some uncertainties about how best to model this particular case. I'd appreciate any suggestions for this fairly simple scenario.
When a production task begins, two people are involved at all times. One is in charge of the production, and a second is tasked with quality assurance. For any task in the database, it must be possible to identify these two people. They'll both exist in a Person table and have IDs, so I just want the best way to relate them to the production task. The following rules exist:
Either person may be swapped out for a different person at any time.
Each task always involves both people (Neither of these are null).
There are never any other people involved in the task that we want to record.
Each person may be involved in multiple tasks, or none at all.
If we had a whole host of relationships between the task and the people, I'd create some sort of convoluted relationship structure describing their relationship (As producer, quality assurance person, overseer, etc.), but here I feel as though it's sensible to just stick the IDs of the two people in the Task table, in separate columns for Production Person and Quality Assurance Person. Is this bad for some reason that I can't see?
What has really prompted my question is that I'm trying to design exactly that in DBDesigner 4, which I'm new to, and it just doesn't like it - When I try to set up a second non-identifying relationship between Task and Person, it won't give me a second field. It also won't seem to let me rename the fields in Task that refer to the persons, so it'd be impossible to differentiate between the two anyway. Since no-one else seems to share this problem, I've began to wonder whether it's a good idea at all. Is it standard to introduce additional tables as soon as there are two or more links between two entities? What would that look like if I wanted to enforce the above rules? I can't see how I'd ensure that an n:m table always has entries for both people working on the task.
If you are confident your requirements will stay this rigid forever, then just create two NOT NULL FKs:
This declaratively enforces that exactly two people are associated to the task at all times, which would not be readily achievable with just the junction table (as you already noted).
OTOH, if you anticipate your requirements might change at some point in the future, then the added flexibility of junction table might be more important than the completely declarative enforcement of your business rules.
I'm not familiar with DBDesigner, and therefore with your particular problem, but in ER modeling in general, multiple relationships with the same entity are distinguished by their "rolenames" which determine the names of migrated attributes (see the section on "Rolenames" in the chapter 3 of the ERwin Methods Guide). Try locating something along those lines in the UI of your tool.
If you want to know the current state and not who held the role previously #Branko Dimitrijevic's solution will work.
But if the statement 'Either person may be swapped out for a different person at any time' implies you need to know who previously held that role consider a 3 table design
Task; TaskID, <other details>
Assignee; TaskID, PeopleID, role, start_date, end_date
People; PeopleID, <other details>
Then in the assignee table you need constraints to ensure that for each TaskID, Role combination the dates are reasonable e.g. dates don't overlap or have gaps. That you have only 1 of each role active for each task at a time. To manage this would probably require code either in triggers or the application.
I have a schema with a number of many to many relationships and what I'm seeing is a alot of similar data structure spread out among tables with different names. The intuition I have is that there is a more efficient/desirable way to achieve the same result but I'm not sure what alternative approaches fall into reasonable design/best practices.
Note: Counries, TrafficTypes and People - as they exist now - could all be represented by Id and Name columns, but in the future may have additional fields. Maybe what I'm after is some kind of technique akin to inheritance?
Here's the diagram of what I've got:
Don't lump together things which you think are similar; they may diverge later when you need to store more information about each entity.
Is there a problem with the number of tables you have in your database?
You are probably thinking about the problem from an object oriented design position and thinking you can use some sort of "parent" table to represent the common parts - databases don't work that way.
If you are not careful you will end up with a MUCK or OTLT table.
Off the bat, I would keep seperate enties/objects/(cars vs animals) in seperate tables.
The chances of such enties overlapping properties are slim at best.
Thing is, once those entites start to evolve in your system, you will find that a single table will have hundreds of columns with singles populated per entity.
I don't see how inheritance applies to your case. But if you are interested in inheritance, as it applies to SQL tables or relations, here are some things to look up:
At the level of ER modeling look up "ER model specialization". This is the way the extended ER model diagrams "is A" relationships.
At the level of table design, look up "Class Table Inheritance" and "Shared primary key" for a couple of techniques that, used together, sort of mimic what inheritance does for you in an OOP. You might also want to look up "single table inheritance" for an alternative that's simpler, but can be more wasteful.
Don't worry. You're doing it right.
In a highly normalized schema, you're going to have tons of tables that are nearly identical.
As the others have said, what you're starting to consider (a generic table for multiple things) is a very bad idea and has many drawbacks.
The biggest drawback is that your relationships are made useless by it, in terms of maintaining data integrity. There's nothing stopping someone from assigning a CountryCode where a TrafficTypeId should be, and so on.
Another drawback would be that having one larger table will likely perform worse than many smaller, specialized tables; due to extra, unnecessary blocking.
Your may still want to implement some type of inheritance concept, but that'll be best done in whatever code accesses the database.