Confusion about 1:1 relationship_问答_开发者_运维开发者技术经验分享

I've been learning database design and I'm confused about 1:1 relationships. From what I understand, you can simply add columns to开发者_如何学C the appropriate table. Can someone provide a real world example of where a 1:1 relationship was either necessary or provided some significant benefit? I.e., where would I use a 1:1 relationship and what would it look like?

I'll give you a real practical example.

In the medical billing world, doctors who want to get paid by medicare handle billing by creating a dictation report for each visit with a patient. This might actually be a recorded audio dictation transcribed by a secretary, but more often it's just a written description of what they did and talked about with the patient, along with history, impressions, and so forth. A licensed medical coder will then read this dictation and decide what the doctor is allowed to bill.

Separate from the dictation, there is demographic information about the patient involved: name, age, billing address, etc. This information must be strictly separate from information about the dictation, to prevent coders from allowing bias to cloud their billing judgements or violating patients' privacy.

This data is often kept well-normalized with a 1:many relationship in the data systems at the point of origin, and only the right parts are displayed to the right people at the right times. However, a significant number of offices out-source their billing function to a third party. This way a small clinic, for example, doesn't have to keep a licensed medical coder on staff; one coder at the billing office can handle the needs of many clinics. When the data is sent from the clinic to the billing office, the patient demographic information and the dictations need to come over as separate pieces, possibly at separate times. At this point, they'll likely be stored in completely separate tables with a 1:1 relationship and a shared ID field to match them up later.

In this case, the 1:1 relationship has very little to do with the data model. You could probably match up the records at the time of import, and as a bill moves through the system eventually the provincial patient information received in the clinic's demographic record will be matched to a real person so the 1:many relationship can be restored. Otherwise you'd get a separate statement on a separate account for each visit to the doctor.

Instead, it has almost everything to do with the systems design. There are likely entirely different people building and using the billing part verses the coding part at our imaginary billing service. This way, each side can each have full control of it's own fiefdom, and you are sure that no one, not even a developer, is breaking any privacy rules.

True one-to-one relationships seldom occur in the real world. This type of relationship is often created to get around some limitation of the database management software rather than to model a real-world situation. In Microsoft Access, one-to-one relationships may be necessary in a database when you have to split a table into two or more tables because of security or performance concerns or because of the limit of 255 columns per table. For example, you might keep most patient information in tblPatient, but put especially sensitive information (e.g., patient name, social security number and address) in tblConfidential (see Figure 3). Access to the information in tblConfidential could be more restricted than for tblPatient. As a second example, perhaps you need to transfer only a portion of a large table to some other application on a regular basis. You can split the table into the transferred and the non-transferred pieces, and join them in a one-to-one relationship.

That's a quote from here: Fundamentals of Relational Database Design

And here's a similar question on SO.

Another reason I can see for using a 1:1 (where I have used it in the past) is if you have a table with a lot of columns, and only a few of them are involved in very intensive and frequent queries which need to be fast, I would break it into two tables that are related 1:1 where I could query the lightweight table and get good performance, but still have the other data related to it easily with a simple join.

I belief tables should be designed with the domain background. So if those columns form two different entities, they should not be mixed in one table. From my experience 1:1 relationships tend to evolve into 1:n relationships over time.

For example you may want to store the postal address of a person. But after some time, you are required to store more than one address per person. Refactoring programs from a 1:1 relationship into 1:n is usually a lot easier than extracting some columns from an old table into a new one.

Many database systems allow defining of access permissions per table in a very easy way. But defining permissions on individual columns is often quite painful.

It's useful if X has a 1:1 relationship with Y and Z also has a 1:1 relationship with Y. Y can be abstracted out into a shared table rather than duplicating in both X and Z.

EDIT: A real world example would be Customers, Companies, and Addresses. There can be a N:N relationship between Customer and Company. But both Customer and Company have 1:1 relationships with Address. Some Address rows could be related to both a Customer and a Person.

First, because they are talking about Access (Jet, Ace, whatever) -- credit to @Richard DesLonde for spotting this -- then they are probably talking about 1:0..1 relationships. I do not believe true 1:1 relationships are workable in Access because it has no mechanism for deferring constraints nor executing multiple statements in a SQL PROCEDURE. Most Access practitioners are satisfied to use a 1:0..1 relationship to model a true 1:1 relationship, so I guess the authors are satisfied to use the term "1:1" informally to refer to both.

Of course, 1:1 and 1:1..0 relationships are common enough in the real world. I rather think they are trying to convey the (valid) point that some 1:1 and 1:1..0 relationships are invented in a data model for business purposes.

Consider a "natural person" (i.e. human) and a "corporation". They have no attributes in common (sure, both have a "name" but their domains are different e.g. "natural person name" has sub atomic domains for "family name", "given name" and "title", etc).

However, in a given data model distinct entity types may play the same role. For example, both a "natural person" and a "corporation" can be the officer of a "corporation". In the data model, we could have two distinct entity types "natural person officers" and "corporate officers" that are likely to have many attributes in common and from the same domains e.g. appointment date, termination date, etc; further, they business rules would be the same e.g. appointment date must be before termination date. Also, both would participate in equivalent relationships e.g. "natural person representing", etc.

The data model could be 'split' at high level, resulting in pairs of very similar tables e.g. "natural person officer" and "corporate officer", "natural person officer natural person representing" and "corporate officer natural person representing", etc.

However, another approach is to model the common attributes and relationships using a fabricated entity type. For example, both a "natural person" and a "corporation" could be considered to be a "legal person" (aside: there is such a concept of "legal person" in law but does this mean the same as existing in the real world?!)

Therefore, we could have a superclass table for "legal persons" and subtype tables for "natural persons" and "corporations" respectively. The "officers" table would reference the "legal persons" table. All subsequent relationship tables could reference the "officers" table, which would half the number of tables from this point down.

There are practical problems to such a 'subclassing' approach. Because a "natural person" and a "corporation" has no attributes in common, they have no common key, therefore the "legal persons" table would need to have an artificial key, with all the problems that this entails, especially if it needs to be exposed in the application. Also, because the relationships between "legal persons", "natural persons" and "corporations" are truly 1:1 some DBMSs, as Access, will lack the necessary functionality to effectively implement them and many will have to settle for making them 1:0..1.

A 1:1 relationship is an abstract concept that you model in your data, but at the database level (assuming RDBMS) doesn't really exist. You always have a foreign key on one table pointing to another, so technically the parent table being pointed to by the FK could have multiple children. This is something you'll want to enforce in your business logic.

A good example of a 1:1 relationship in a modeling sense would be the relationship between employee and person. You have a person with certain data, then you have extra attributes on that same person that you put on an employee. A good way to think of this in OO programming terms is as inherited classes. The Employee class, inherits from Person. In fact may ORM systems will model the 1:1 relationship in the database with each table having a shared primary key.