هل يمكن أيضًا استخدام جدول الوصلات (جدول الانضمام) لعلاقة رأس بأطراف؟

Question

وبحسب تعريف أ جدول الوصلات (جدول الجسر/جدول الارتباط) يُستخدم للعلاقات متعدد إلى متعدد، عند استخدامه على النحو التالي:

CREATE TABLE Users
(
UserLogin varchar(50) PRIMARY KEY,
UserPassword varchar(50) NOT NULL,
UserName varchar(50) NOT NULL
)


CREATE TABLE Permissions
(
PermissionKey varchar(50) PRIMARY KEY,
PermissionDescription varchar(500) NOT NULL
)


--This is the junction table.
CREATE TABLE UserPermissions
(
UserLogin varchar(50) REFERENCES Users (UserLogin),
PermissionKey varchar(50) REFERENCES Permissions (PermissionKey),
PRIMARY KEY (UserLogin, PermissionKey)
)

ولكن ألا يمكن استخدامه أيضًا بنفس السهولة في علاقات رأس بأطراف، كما في هذا المثال الذي يرتبط فيه مستخدم واحد بالعديد من الطلبات:

(لا أفهم قواعد البيانات جيدًا لذا يرجى تصحيحي إذا أساءت فهم شيء ما.)

CREATE TABLE Users
(
UserLogin varchar(50) PRIMARY KEY,
UserPassword varchar(50) NOT NULL,
UserName varchar(50) NOT NULL
)


CREATE TABLE Orders
(
OrderKey varchar(50) PRIMARY KEY,
OrderDescription varchar(500) NOT NULL
)


--This is the junction table.
CREATE TABLE UserOrders
(
UserLogin varchar(50) REFERENCES Users (UserLogin),
OrderKey varchar(50) REFERENCES Orders (OrderKey),
PRIMARY KEY (UserLogin, OrderKey)
)

Answer 1

نعم، لا يزال من الممكن تخزين علاقة رأس بأطراف وفرضها في جدول الوصلات.

في المثال الخاص بك، لا تقوم بفرض أي قيود على UserOrders جدول الوصلات، لذلك يمكن أن ينتمي طلب واحد إلى مستخدمين (بافتراض أن هذا غير صحيح).لفرض ذلك يمكنك القيام به OrderKey يكون المفتاح الأساسي لل UserOrders جدول الوصلات (أو لديك قيد فريد على هذا العمود).من الناحية الفنية سوف يصبح مجرد كثير إلى واحد العلاقة بين UserOrders و Users, ، في حين وجود واحد لواحد العلاقة بين Orders و UserOrders.

لا أستطيع إلا أن أفكر في سبب واحد لتصميم كثير إلى واحد العلاقة باستخدام جدول الوصلات - إذا كنت تخطط للسماح بـ الكثير للكثيرين العلاقة في المستقبل ولا ترغب في التعامل مع ترحيل البيانات.ولكن في هذه الأثناء ستدفع تكلفة التخزين والربط بطاولة إضافية.

Answer 2

لا يوجد أي سبب لوجود جدول الوصلات لا أستطيع يمكن استخدامها لعلاقة رأس بأطراف.السؤال هو عادة واحد من الأداء.لماذا تجعل قاعدة البيانات تنضم إلى جدول إضافي عندما يكون ذلك غير ضروري؟

Answer 3

سيكون هذا من كثير إلى كثير:

CREATE TABLE UserOrders
(UserLogin varchar(50) REFERENCES Users (UserLogin),
OrderKey varchar(50) REFERENCES Orders (OrderKey),
PRIMARY KEY (UserLogin, OrderKey));

سيكون هذا واحدًا لكثير (مستخدم واحد لديه العديد من الطلبات):

CREATE TABLE UserOrders
(UserLogin varchar(50) REFERENCES Users (UserLogin),
OrderKey varchar(50) REFERENCES Orders (OrderKey),
PRIMARY KEY (OrderKey));

لاحظ الفرق في قيد PRIMARY KEY.

Answer 4

بمجرد إنشاء جدول، فإنه لا يحتوي حقًا على نوع جدول "الوصلات" أو الجدول "الارتباطي" أو جدول "الانضمام" - إنه مجرد جدول.

نستخدم هذه المصطلحات لوصف سبب محدد لإنشاء الكيان (والجدول الناتج) في البداية.يتم إنشاء الكيانات الترابطية، في البداية، لحل موقف متعدد إلى متعدد.لكن هذه الجداول غالبًا ما تحتوي على سمات خاصة بها (مثل وقت الاقتران، وسبب الاقتران، وما إلى ذلك).لذا، ليس لدى SQL Server أو Oracle أو التعليمات البرمجية الخاصة بك أي سبب لمعرفة سبب إنشاء الجدول... فقط إنه جدول.

من وجهة نظر فنية، لا يوجد أي فرق بين الجدول الترابطي وأي جدول آخر.

لذلك يمكن لهذه الجداول أن تملأ أي دور يمكن أن يؤديه أي جدول آخر.لا توجد قواعد حول كيفية ربط الجداول الأخرى بها أيضًا.

Answer 5

يمكنك فرض قيد "واحد" في جدول الانضمام/الوصلات بإضافة قيد فريد (أو جعله المفتاح الأساسي لجدول الربط، لأن تلك السمة نفسها تحدد العلاقة) إلى العمود الذي يمثل مفتاحًا خارجيًا لـ " كثيرة "الجانب.وذلك لأنك تريد أن يكون للـ rwos في الجانب المتعدد علاقة واحدة فقط ويتم ذكر العلاقات في جدول الانضمام/الوصل.

Answer 6

أعتقد أنك فهمت المفهوم بشكل خاطئ - إليك الشرح البسيط إذا كان يمكن أن يساعدك:لتحقيق علاقة متعدد-متعدد بين جدولين (على سبيل المثال، A وB)، نحتاج إلى الاستعانة بجدول الوصلات (على سبيل المثال، الجدول c) الذي سيكون له علاقة واحد-متعدد مع كلا الجدولين A وB.