I need to create a simple schema which would hold the relationship between a parent and child.
I have two approaches here
Approach 1
Have a parent table
Have a child table and add the parent id as a foreign key dependency to it.
Approach 2
Have a parent table
Have a child table
)Have a mapping table which identifies the relationship between parent and child(i.e parent and child are independent tables)
I know this is a bit of a silly question.But, still would like to know which approach is more recommended in the longer run as per the industry standards if any(as per recommended db design approaches)
My ORM implementation would be Hibernate.
It depends. First off, I take it that a child parent relationship is many to one.
So approach 1 will work. The relationship is constrained to be many to one because a foreign key is juxtaposed with a primary key, and the primary key is constrained to be unique.
There are two problems with approach 2: First, it adds complexity without adding power. Second, it doesn't enforce the many to one nature of the relationship. It's going to take an extra constraint or careful application code to prevent a many to many situation arising in the data.
There is, however, an unusual case where approach 2 is worth it. It's where there is a reasonable expectation that the relationship will become many to many in the near future. In this case, approach 2 will require almost no changes to the database and no changes to the existing data in order to accommodate the new requirement.
These two approaches model different things, so this is not a matter of what is more "recommended", but what fits your requirements.
The approach 1 models one-to-many relationship.
The approach 2 models many-to-many relationship1.
1 And the table in the middle is commonly called "junction" or "link" table.
I'm trying to get my head around the differences between 3NF and BCNF and I think I'm getting there but it would be great if anyone can help out.
The following is a series of relations in the 3rd normal form (helpfully stolen from Identifying Functional Dependencies which in turn took them from Connolly & Begg's Database Systems):
Client {clientNo(PK), clientName}
Owner {ownerNo(PK), ownerName}
Property {propertyNo (PK), propertyAddress, rent}
ClientRental {clientNo(PK), propertyNo(PK), rentStart, rentFinish, ownerNo(FK)}
Each property has only one owner and clients can rent those properties. Assume rent is fixed for each property.
So my question is: Are these also in the BCNF?
My hunch is the ClientRental relation is not because PropertyNo->ownerNo. So PropertyNo is a determinant in a functional dependency but it isn't a superkey.
Am is anywhere near the right ballpark?
The short, informal way to express the difference is that, in BCNF, every "arrow" for every functional dependency is an "arrow" out of a candidate key. For a relation that's in 3NF, but isn't in BCNF, there will be at least one "arrow" out of something besides a candidate key.
Wikipedia entry for 3NF table not meeting BCNF
A common misconception is that you can normalize to 2NF and no higher, then to 3NF and no higher, then to BCNF and no higher. In fact, fixing a partial key dependency in order to reach 2NF often leaves you with all relations in 5NF. That is, you went from one relation in 2NF to multiple relations in 5NF without stopping at BCNF in between.
I have a column with a uniqueidentifier that can potentially reference one of four different tables. I have seen this done in two ways, but both seem like bad practice.
First, I've seen a single ObjectID column without explicitly declaring it as a foreign key to a specific table. Then you can just shove any uniqueidentifier you want in it. This means you could potentially insert IDs from tables that are not part of the 4 tables I wanted.
Second, because the data can come from four different tables, I've also seen people make 4 different foreign keys. And in doing so, the system relies on ONE AND ONLY ONE column having a non-NULL value.
What's a better approach to doing this? For example, records in my table could potentially reference Hospitals(ID), Clinics(ID), Schools(ID), or Universities(ID)... but ONLY those tables.
Thanks!
You might want to consider a Type/SubType data model. This is very much like class/subclasses in object oriented programming, but much more awkward to implement, and no RDBMS (that I am aware of) natively supports them. The general idea is:
You define a Type (Building), create a table for it, give it a primary key
You define two or more sub-types (here, Hospital, Clinic, School, University), create tables for each of them, make primary keys… but the primary keys are also foreign keys that reference the Building table
Your table with one “ObjectType” column can now be built with a foreign key onto the Building table. You’d have to join a few tables to determine what kind of building it is, but you’d have to do that anyway. That, or store redundant data.
You have noticed the problem with this model, right? What’s to keep a Building from having entries in in two or more of the subtype tables? Glad you asked:
Add a column, perhaps “BuildingType”, to Building, say char(1) with allowed values of {H, C, S, U} indicating (duh) type of building.
Build a unique constraint on BuildingID + BuildingType
Have the BulidingType column in the subtables. Put a check constraint on it so that it can only ever be set to the value (H for the Hospitals table, etc.) In theory, this could be a computed column; in practice, this won't work because of the following step:
Build the foreign key to relate the tables using both columns
Voila: Given a BUILDING row set with type H, an entry in the SCHOOL table (with type S) cannot be set to reference that Building
You will recall that I did say it was hard to implement.
In fact, the big question is: Is this worth doing? If it makes sense to implement the four (or more, as time passes) building types as type/subtype (further normalization advantages: one place for address and other attributes common to every building, with building-specific attributes stored in the subtables), it may well be worth the extra effort to build and maintain. If not, then you’re back to square one: a logical model that is hard to implement in the average modern-day RDBMS.
Let's start at the conceptual level. If we think of Hospitals, Clinics, Schools, and Universities as classes of subject matter entities, is there a superclass that generalizes all of them? There probably is. I'm not going to try to tell you what it is, because I don't understand your subject matter as well as you do. But I'm going to proceed as if we can call all of them "Institutions", and treat each of the four as subclasses of Institutions.
As other responders have noted, class/subclass extension and inheritance are not built into most relational database systems. But there is plenty of assistance, if you know the right buzzwords. What follows is intended to teach you the buzzwords, in database lingo. Here is a summary of the buzzwords coming: "ER Generalization", "ER Specialization", "Single Table Inheritance", "Class Table Inheritance", "Shared Primary Key".
Staying at the conceptual level, ER modeling is a good way of understanding the data at a conceptual level. In ER modeling, there is a concept, "ER Generalization", and a counterpart concept "ER Specialization" that parallel the thought process I just presented above as "superclass/subclass". ER Specialization tells you how to diagram subclasses, but it doesn't tell you how to implement them.
Next we move down from the conceptual level to the logical level. We express the data in terms of relations or, if you will, SQL tables. There are a couple of techniques for implementing subclasses. One is called "Single Table Inheritance". The other is called "Class Table Inheritance". In connection with Class table inheritance, there is another technique that goes by the name "Shared primary Key".
Going forward in your case with class table inheritance, we first design a table called "Institutions", with an Id field, a name field, and all of the fields that pertain to institutions, no matter which of the four kinds they are. Things like mailing address fields, for instance. Again, you understand your data better than I do, and you can find fields that are in all four of your existing tables. We populate the id field in the usual way.
Next we design four tables called "Hospitals", "Clinics", "Schools", and "Universities". These will contain an id field, plus all of the data fields that pertain only to that kind of institution. For instance, a hospital might have a "bed capacity". Again, you understand your data better than I do, and you can figure these out from the fields in your existing tables that didn't make it into the Institutions table.
This is where "shared primary key" comes in. When a new entry is made into "Institutions", we have to make a new parallel entry into one of four specialized subclass tables. But we don't use some sort of autonumber feature to populate the id field. Instead, we put a copy of the id field from the "Institutions" table into the id field of the subclass table.
This is a little work, but the benefits are well worth the effort. Shared primary key enforces the one-to-one nature of the relationship between subclass entries and superclass entries. It makes joining superclass data and subclass data simple, easy, and fast. It eliminates the need for a special field to tell you which subclass a given institution belongs in.
And, in your case, it provides a handy answer to your original question. The foreign key you were originally asking about is now always a foreign key to the Institutions table. And, because of the magic of shared-primary-key, the foreign key also references the entry in the appropriate subclass table, with no extra work.
You can create four views that combine institution data with each of the four subclass tables, for convenience.
Look up "ER Specialization", "Class Table Inheritance", "Shared Primary Key", and maybe "Single Table Inheritance" on the web, and here in SO. There are tags for most of these concepts or techniques here in SO.
You could put a trigger on the table and enforce the referential integrity there. I don't think there's a really good out-of-the-box feature to implement this requirement.
I'm currently revising for an upcoming Database Management exam.
There is a question on denormalising the sample employees database. The question is as follows, the schema is also shown below:
Question:
Use the 'employees' database to de-normalise any two (or more) tables to produce a table in 2NF. you must precisely explain why the table is in 2NF and not 3NF.
Schema:
My Answer:
I would denormalise the 'salaries' table into the 'employees' table to. To normalise I would move {salary, from_date, to_date} into the employees table and remove the 'salaries' table. Note: from_date is no longer part of the primary key in 'employees'.
The 'employees' table is no longer in 3NF and is now in 2NF. This is because a 'transitive dependency' has been introduced into the table.
The transitive dependency is as follows: 'salary' depends on 'from_date'. It is transitive and not partial because 'from_date' is not a component of the primary key. In a partial dependency the determinant must be part of the primary key.
Basically for this question I need to create a transitive dependency. This schema seems a little sparse and I'm also a little thrown off by the fact that dates are part of primary keys.
If the above dependency is wrong could somebody possible point one out for me please?
Another possible solution is to denormalise 'departments' into 'dept_emp'. I could add the 'dept_name' into 'dept_emp'. But from looking at the SQL for this table shows 'dept_no' is part of the primary key.
Any guidance on this would be greatly appreciated.
Hi I have been thinking for hours about a database normalization problem that I am trying to solve. In my problem I have a composite primary key and data in one of the columns of the key has multiple values. Multiple values within one of the columns of the primary key is the major problem. I want to know whether in first normal form only repeating groups other than primary key will be removed or primary key column having multiple values will also be removed. Still may be its nebulous for you people to understand. So I am posting screenshot of the table:
http://tinypic.com/view.php?pic=ev47jr&s=5
(Kindly open the image above to see the table)
Here the question I wanna ask is that whether in first normal form only column number 4,5,6,7 will be removed or column number 2 will also be removed (Since it also contains multiple values)?
If I don't remove 2nd column then it won't come in 1NF, but if I remove it too, then it will go to 3NF directly. Help?
Thank you.
Here the question I wanna ask is that whether in first normal form
only column number 4,5,6,7 will be removed or column number 2 will
also be removed
All columns containing multiple values will be changed. That includes column 2.
If I don't remove 2nd column then it won't come in 1NF, but if I
remove it too, then it will go to 3NF directly.
Normalization doesn't work like this:
Determine the structure that is in 1NF, but is not yet in 2NF.
Determine the structure that is in 2NF, but is not yet in 3NF.
Determine the structure that is in 3NF, but is not yet in BCNF.
Determine the structure that is in BCNF, but is not yet in 4NF.
Determine the structure that is in 4NF, but is not yet in 5NF.
Determine the structure that is in 5NF, but is not yet in 6NF.
The relational model doesn't say that for every relation R that is in 1NF, there exists a decomposition that is in 2NF, but is not yet in 3NF. It just doesn't say that, but this is a common misunderstanding.
In practice, it's not unusual to remove a partial key dependency to get to 2NF, and find the results to be in 5NF.