ER 다이어그램 관계

저는 자전거 가게의 ER 다이어그램을 디자인하는 데 어려움을 겪고 있습니다. 이 가게에는 다른 특성을 가진 많은 자전거 부품 (휠, 기어, 브레이크 등)이 있습니다. 따라서 나는 각자의 속성을 모델링하기 위해 각 부분을 하나의 개체로 삼았다. 그들은 모두 상속을 사용하여 만든 수량 속성, 이름 및 가격을 포함합니다. 그러나 이제는이 모든 엔티티가있을 때 모든 파트의 콜렉션 인 'Bike'엔티티와 모든 파트가 나열된 'Stock'엔티티와 해당 선호량 및 최소 금액에 맵핑되어야합니다.ER 다이어그램 관계

제 문제는 부품을 'Bike'및 'Stock'엔티티에 매핑하는 방법을 모르겠다는 것입니다. 아래 그림에서 두 가지 다른 디자인을 만들었습니다. 어떤 것이 든 올바른지 어느 것입니까? 더 똑똑한 방식으로 모델링 할 수 있습니까?

해결 방법 1 개 Solution 1 솔루션 중 2

enter image description here

출처

2014-02-17 barto90

Bill의 재료 유형 스키마를 살펴 보았습니다. 여기에는 Part의 특정 유형에 대한 특정 세부 정보를 보유하려는 Part 수퍼 유형과 많은 하위 유형이 있습니다. BOM에는 부모 파트를 만드는 데 필요한 하위 파트 수 (예 : 2 휠, 1 프레임)를 보유 할 수량이 포함됩니다. 이것은 Part의 다른 유형 인 Bike까지 계속 이어집니다. 부품은 재고 및 재고 관리를 위해 엔티티에 연결할 수 있습니다.

   +-----------------+ 
       | BOM    | 
       +-----------------+ 
       | parent_part_id | 
       | child_part_no | 
       | quantity  | 
       +-----------------+ 
        |  |   
        |  |   +-------------+ 
        |  |   | STOCK  | 
       +-------------+  +-------------+ 
       | PART  |-----| ...   | 
       +-------------+  +-------------+ 
       | part_id  | 
       | part_type |  
     +---------| ...   |---------+ 
     |   +-------------+   | 
     |    |    | 
     |    |    | 
     |    |    | 
+-------------+ +-------------+ +-------------+ 
| WHEEL  | | GEAR  | | BIKE  | 
+-------------+ +-------------+ +-------------+ 
| part_id  | | part_id  | | part_id  | 
| ...   | | ...   | | ...   | 
+-------------+ +-------------+ +-------------+

출처

2014-02-18 19:49:00 DrabJay

훌륭한 솔루션입니다. 감사 – barto90

없음 (나는 단순화의 속성을 제거했습니다). 죄송합니다.

우선, 별도의 엔티티 대신 "휠", "기어", "브레이크"를 단일 엔티티 "부품"으로 간주 할 수 있습니다.

그러면 다이어그램이 더 단순 해집니다. 그리고 "체인", "조명"등과 같이 더 많은 부분이있을 수 있다는 것보다 기억하십시오.

그래서 각 부품에 sngle 엔티티를 정의하는 대신 하나의 부품, 즉 "부품"을 정의하십시오.

둘째, 일부 부품은 다른 부품의 부품이 될 수 있습니다. 이를 "재귀 적"또는 "자체 참조 된"엔터티라고합니다. 처음에는 이상하게 보일 수 있지만 다이어그램을보다 단순하게 만듭니다.

............................................................ 
...........+-------------+.................................. 
...........|.............|.................................. 
...........|.............|.................................. 
.........../\............|.........../\..................... 
........../ \...........|........../ \.................... 
........./ \.....Many.|....Many./ \................... 
......../  \.1.+-----+----+.../  \...1+----------+.. 
.......<IsPartOf>--| Part +--<Stores>---+ Stock |.. 
........\  /...+----------+...\  /....+----------+.. 
.........\ /.........|..........\ /................... 
..........\ /..........|Many.......\ /.................... 
...........\/...........|............\/..................... 
......................./ \................................. 
....................../ \................................ 
...................../  \............................... 
..................../  \.............................. 
...................<Composed>............................. 
....................\ By /.............................. 
.....................\  /............................... 
......................\ /................................ 
.......................\../................................. 
........................|................................... 
........................|1.................................. 
...................+----------+............................. 
...................| Bike |............................. 
...................+----------+............................. 
............................................................

건배.

출처

2014-02-17 19:00:09 umlcat

나는이 옵션을 고려해 보았지만 다른 부분에는 다른 속성과 속성 수가 있습니다. 그래서 나는 그것이이 경우 선택 사항이라고 생각하지 않습니다. 공통점이있는 속성 (price, name, id)은 상속받은 다른 엔티티로 구분됩니다. – barto90

ER 다이어그램 관계

답변

관련 문제