I've got the following business requirements for a scenario:
http://ompldr.org/vN2ZvdQ
and I came up with the following UML diagrams to model the relationship:
http://ompldr.org/vN2Y5Yg
I was wondering whether I have successfully managed to implement all the relations in the E-R model, especially the 1..* relationship. Furthermore, it is my understanding that mandatory relationships cannot be implemented just by using FK/PK so I have to add additional constraints, is that so?
Its seems to be ok. You can use ERWin or DBDesigner to doing your work in a easier way.
Consider ON DELETE CASCADE, ON UPDATE CASCADE, etc in your constraints.
Related
I feel like I have searched through the internet to find an answer to this question for quite some time now, but without success. Does anyone feel comfortable explaining why many-to-many relationships should be replaced with a bridge table?
Probably most (all??) RDMS implement a M:N relationship by creating a table containing two columns with the FKs.
So there is no advantage to explicitely model the bridge table.
But in most realistic cases you want to store additional information (besides the fact of its existence) about the relationship instance, e.g. timestamp and user from the creation. That means that you need to model the bridge table anyway.
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.
Should I build the relationships with the database schema or deal with them programmatically?
For Example When I build the database in MSSQL I can to not build the relationships and deal with the relationships programmatically like checking if a key is exist as a primary key in another table and determine upon that to insert the new row to the table or not.
could anyone advise me if it is a good practice or not.
DO make relationships between tables explicit by declaring foreign key constraints.
I do not see any good reason for not doing this. Why are foreign key constraints a good idea?
Foreign key constraints are a simple way to help safeguard data integrity/consistency.
Constraints (not just foreign key ones) can also be seen as a form of "living documentation" (making things explicit and therefore discoverable, without having to guess).
You might still want to validate inserts in code; in that case you can look at foreign key constraints as a "safety net", in case your code fails.
(Regarding the second bullet point above: I have to work with one legacy database which is lacking some foreign key constraints that should by all means have been declared. This means that every time I have to make a change to it, I might inadvertently break an application that makes certain assumptions about the schema that aren't obvious by looking at the schema. Working with this database is very painful and error-prone. If I could change one thing about this database, it would be to add all missing constraints.)
it depends upon your need.
If you are designing OLTP applciation then builing relationship is good but if you designing datawarehouse DWH or datamart then it is advisable not to establish relationship in schema and handle it in code.
Recently I've asked a question about the best way to go to design a DB schema to support multiple types of users and interactions between them, one of the answers suggested that I use one table for each user type and Distributed Keys.
The thing is the only databases I actively work with are MySQL and SQLite and I've always done this kinda of work of maintaining the integrity of the DB on the programming side and never directly in the database, can someone point me to a detailed yet easy to understand guide on foreign keys, references and related subjects?
Thanks in advance!
EDIT: I'm interested specifically in MySQL usage examples and documentation, I've already searched in the MySQL manual but nothing useful comes up.
This isn't MySQL-specific, but there is some good stuff in here
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
I don't agree with him about the use of natural keys versus surrogate keys. I have found surrogate keys in general work better for primary keys, but if you have a natural key you should put a unique index on it to prevent duplication of data. Pay particular attention to the sections on:
- Not using SQL facilities to protect data integrity
- Trying to code generic T-SQL objects
- One table to hold all domain values
Another good starting place is:
http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx [dead link Feb 17, 2015]
Try these:
http://en.wikipedia.org/wiki/Relational_database (has links to articles on Constraints, Foreign keys, Stored procedures, Indices, etc.)
http://en.wikipedia.org/wiki/Database
Try this one: Relational Database Design Basics or the Wiki. Give this a read too.
Specifically related to MySQL:
Referential Integrity in MySQL
Foreign Keys and Referential Integrity
Also this stackoverflow question: MYSQL and RDBMS
If you like to read books, try Beginning Database Design: From Novice to Professional by Clare Churcher. You can take a look it at google books.
Hugh Darwen has made his course on Relational Algebra/Database Technology publicly and freely available. Search for "An Introduction to Relational Database Theory" on http://www.thethirdmanifesto.com
It's introductory, so nothing "advanced", but at least you won't be told anything that is an outright violation of the theory.
I've recently been reading Louis Davidson's book on Sql Server Database Design and found it quite informative. I've picked up on alot of concepts that I didn't previously know alot (or anything) about. Primarily - I picked up on a way to set up database relationships that I hand't tried before.
Basically you use a surrogate key as the tables PK (an auto incremented id field) and then set up one or more Alternate Keys consisting of one or more Unique keys. Theese alternate kays would then be the values used for relationships (or the PK, if that makes more sense for the given relationship).
I remodelled an old database that was suffering from some data inconsitencies due to poor design to implement this, to me, new way of thinking.
On a database level it works great. Tha relationships function the way they're supposed to and the constraints are enforced in a consistent, reliable manner.
HOWEVER
I cannot get it to work properly in either the Entity Framework or in Linq to Sql classes. I read that in V1 of EF, it just flat out won't support this kind of relationship - so I moved to Linq to Sql to see if things would work out better. They seemingly did, as I got all the relationships automatically mapped out when I imported the classes from my database. The problem is that I can't save data to the database because of InvalidCastOperation exceptions as soon as I try to save data.
So I have a couple of questions:
Is this a limitation in Linq To Sql?
If so, is there a way to work around
it? Preferebly without implementing
sprocs for save, update and delete -
type safety is something I would
like to keep.
Is this way of designing database
relationships "correct" and/or a
good practice?
I hope someone can shed some light on this, as I'm getting quite frustrated about it. I can't really find any good material on the subject online - so hopefully someone here has an answer or can point me in the right direction.
Thanks alot!
EDIT - Solution.
What I ended up doing was this - I went back to using the Entity Framework in conjunction with a redesign of the database schema. I remodeled the relationships to rely on primary keys rather than alternate keys, in most cases. Where that was not an option - I made some modifications to the EF layout. I implemented the relationship that relied on the AK's - at which time EF complains. To get around that I had to delete the foreign key property on the many side of the relationship at which point EF accepts the relationship.
1) Yes.
2) If you can mark your alternate key as primary in the L2S model and unmark the real PK as PK then it will work.
3) From the db perspective there's nothing wrong, but as you have noticed it is not supported by L2S or EF. Personally I prefer to always have FKs pointing to the PK and only use AKs for lookups.