일대 다와 다 대일 관계의 차이점

일대 다와 다 대일 관계의 차이점

---

일대 다 관계와 다 대일 관계의 실제 차이점은 무엇입니까? 그것은 단지 반전 된 것입니까?

이 주제에 대한 '좋고 이해하기 쉬운'자습서를 찾을 수 없습니다. 초보자를위한 SQL : Part 3-데이터베이스 관계

---

예, 그 반대입니다. 엔티티가 존재하는 관계의 측면에 따라 다릅니다.

예를 들어, 한 부서가 여러 직원을 고용 할 수있는 경우 부서 간 관계는 일대 다 관계 (1 부서는 많은 직원을 고용 함)이고 직원 대 부서 관계는 다 대일 관계입니다 (많은 직원이 한 부서에서 일함).

관계 유형에 대한 추가 정보 :

데이터베이스 관계-IBM DB2 문서

---

이 페이지에서 데이터베이스 용어에 대해

테이블 간의 대부분의 관계는 일대 다입니다.

예:

• 한 지역은 많은 독자의 서식지가 될 수 있습니다.
• 한 독자가 여러 구독을 가질 수 있습니다.
• 한 신문에 여러 구독이있을 수 있습니다.

다 대일 관계는 일대 다와 동일하지만 관점이 다릅니다.

• 많은 독자들이 한 지역에 살고 있습니다.
• 많은 구독은 동일한 독자가 될 수 있습니다.
• 많은 구독이 동일한 신문에 대한 것입니다.

---

일대 다 관계와 다 대일 관계의 실제 차이점은 무엇입니까?

데이터를 시각화하는 데 도움이되는 이러한 용어 사이에는 개념적 차이점이 있으며 완전히 이해해야하는 생성 된 스키마의 가능한 차이점도 있습니다. 대부분의 차이점은 관점 중 하나입니다.

(A)에 일대 다 관계가, 로컬 테이블에서 다른 테이블 많은 행과 연관 될 수있는 하나 개의 행을 갖는다. 초보자를위한 SQL 의 예에서 하나 Customer는 많은 Orders 와 연관 될 수 있습니다 .

반대의 다 대일 관계에서 로컬 테이블에는 다른 테이블의 한 행과 연관된 많은 행이있을 수 있습니다. 이 예에서 많은는 Order하나에 연결될 수 있습니다 Customer. 이 개념적 차이는 정신적 표현에 중요합니다.

또한 관계를 지원하는 스키마는 Customer및 Order테이블 에서 다르게 표현 될 수 있습니다 . 예를 들어 고객에게 다음 id과 name같은 열이있는 경우

id,name
1,Bill Smith
2,Jim Kenshaw

그런 다음 a Order가에 연결되기 위해 Customer많은 SQL 구현이 Order테이블에 id연결된 의을 저장하는 열을 추가합니다 Customer(이 스키마에서 customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

위의 데이터 행에서 customer_idid 열을 보면 Bill Smith(customer-id # 1)에 2 개의 주문이 연결되어 있음을 알 수 있습니다. 하나는 $ 12.34이고 다른 하나는 $ 7.58입니다. Jim Kenshaw(customer-id # 2) $ 158.01에 대한 주문이 1 개뿐입니다.

알아 두어야 할 중요한 것은 일반적으로 일대 다 관계가 실제로 "일"인 테이블에 열을 추가하지 않는다는 것입니다. 에 Customer와의 관계를 설명하는 추가 열이 없습니다 Order. 실제로에는 및 테이블과 Customer일대 다 관계가 있지만 테이블에 추가 열이 추가되지 않을 수도 있습니다 .ShippingAddressSalesCallCustomer

그러나 다 대일 관계를 설명하기 위해 종종 id"일"테이블에 대한 외래 키인 "다"테이블에 customer_id열이 추가됩니다 Order. 이 경우에는 열이 . $ 12.34에 대한 주문 # 10을에 연결하기 위해 열을 의 ID 1에 Bill Smith할당합니다 .customer_idBill Smith

그러나 Customer및 Order관계 를 설명하는 다른 테이블이있을 수도 있으므로 테이블에 추가 필드를 추가 할 필요가 없습니다 Order. 대신 추가의 customer_id받는 사람 필드를 Order테이블이있을 수 있습니다 Customer_Order모두에 대한 키를 포함 테이블 Customer과 Order.

customer_id,order_id
1,10
1,11
2,12

이 경우 일대 다 및 다대 일은 스키마 변경이 없기 때문에 모두 개념적입니다. 스키마 및 SQL 구현에 따라 달라지는 메커니즘입니다.

도움이 되었기를 바랍니다.

---

첫 번째 질문에 대한 답은 : 둘 다 비슷합니다.

두 번째 질문에 대한 답은 다음과 같습니다 : 일대 다-> MAN (MAN 테이블)에는 한 명 이상의 아내 (WOMEN 테이블) 다 대일-> 한 명 이상의 여성이 한 MAN과 결혼했습니다.

Now if you want to relate this relation with two tables MAN and WOMEN, one MAN table row may have many relations with rows in the WOMEN table. hope it clear.

---

There is no difference. It's just a matter of language and preference as to which way round you state the relationship.

---

Example

Two tables with one relation

SQL

In SQL, there is only one kind of relationship, it is called a Reference. (Your front end may do helpful or confusing things [such as in some of the Answers], but that is a different story.)

• A Foreign Key in one table (the referencing table)
  References
  a Primary Key in another table (the referenced table)

• In SQL terms, Bar references Foo
  Not the other way around

  CREATE TABLE Foo (
      Foo   CHAR(10)  NOT NULL, -- primary key
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK             -- constraint name
          PRIMARY KEY (Foo)     -- pk
      )  
  CREATE TABLE Bar (
      Bar   CHAR(10)  NOT NULL, -- primary key
      Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK                -- constraint name
          PRIMARY KEY (Bar),       -- pk
      CONSTRAINT Foo_HasMany_Bars  -- constraint name
          FOREIGN KEY   (Foo)      -- fk in (this) referencing table
          REFERENCES Foo(Foo)      -- pk in referenced table
      )
  

• Since Foo.Foo is a Primary Key, it is unique, there is only one row for any given value of Foo

• Since Bar.Foo is a Reference, a Foreign Key, and there is no unique index on it, there can be many rows for any given value of Foo
• Therefore the relation Foo::Bar is one-to-many
• Now you can perceive (look at) the relation the other way around, Bar::Foo is many-to-one
  • But do not let that confuse you: for any one Bar row, there is just one Foo row that it References
• In SQL, that is all we have. That is all that is necessary.

What is the real difference between one to many and many to one relationship?

There is only one relation, therefore there is no difference. Perception (from one "end" or the other "end") or reading it backwards, does not change the relation.

Cardinality

Cardinality is declared first in the data model, which means Logical and Physical (the intent), and then in the implementation (the intent realised).

Cardinality

One to zero-to-many
In SQL that (the above) is all that is required.

One to one-to-many
You need a Transaction to enforce the one in the Referencing table.

One to zero-to-one
You need in Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

One to one
You need a Transaction to enforce the one in the Referencing table.

Many to many
There is no such thing at the Physical level (recall, there is only one type of relation in SQL).

At the early Logical levels during the modelling exercise, it is convenient to draw such a relation. Before the model gets close to implementation, it had better be elevated to using only things that can exist. Such a relation is resolved by implementing an Associative Table.

Many-to-many Resolved

---

One-to-Many and Many-to-One are similar in Multiplicity but not Aspect (i.e. Directionality).

The mapping of Associations between entity classes and the Relationships between tables. There are two categories of Relationships:

1. Multiplicity (ER term: cardinality)
   • One-to-one relationships: Example Husband and Wife
   • One-to-Many relationships: Example Mother and Children
   • Many-to-Many relationships: Example Student and Subject
2. Directionality : Not affect on mapping but makes difference on how we can access data.
   • Uni-directional relationships: A relationship field or property that refers to the other entity.
   • Bi-directional relationships: Each entity has a relationship field or property that refers to the other entity.

---

There's no practical difference. Just use the relationship which makes the most sense given the way you see your problem as Devendra illustrated.

---

• ---One to Many--- A Parents can has two or more children.

• ---Many to one--- Those 3 children can have a single Parents.

  Both are similar. This can be used belongs to the need. If you wanna find children for a particular parents, then u can go with One-To-Many. or else, wanna find parents for a twins, you may go with Many-To-One. Likewise....,

---

one-to-many has parent class contains n number of childrens so it is a collection mapping.

many-to-one has n number of childrens contains one parent so it is a object mapping

참고URL : https://stackoverflow.com/questions/4601703/difference-between-one-to-many-and-many-to-one-relationship