Дъщерна таблица (A.K.A. слаб обект ) е таблица, чиито атрибути на първичен ключ зависят на друга таблица, като по този начин дъщерната таблица е идентифицирана или частично идентифицирани по редове в таблицата зависи от (родител). Редове в дъщерна таблица не могат да съществуват без съответен ред в нейната родителска таблица.
За да илюстрираме, нека вземем прост и напълно уместен пример, с който всички сме запознати:Родители и деца в контекста на семейството . Можем да моделираме тази връзка с таблици по следния начин:
В горния модел всеки ред в Parents таблицата еуникално идентифицирана чрез SSN . SSN е присъщ и уникален атрибут за всеки родител, така че е самостоятелен или „силен“ обект, тъй като не разчита на друга таблица, за да определи своята идентичност.
Децата обаче изискват родител, за да съществува (Parent_SSN трябва препратка към съществуващ SSN в Parents таблица).
Обърнете внимание на съставния първичен ключ (Parent_SSN, Name ) в Children маса. Това означава, че децата сауникално идентифицирани чрез комбинация на Parent_SSN и Name . Не можете да правите заявка за отделно дете въз основа само на Name поле, тъй като няколко родители може да имат деца с едно и също име. По същия начин не можете да правите заявки за отделно дете въз основа само на Parent_SSN поле, защото единият родител може да има много деца. Като се има предвид това, децата са частично идентифицирани от родителите си, следователно идентифицирани връзка.
Но не могат ли децата да бъдат уникално идентифицирани и от SSN? Защо да, разбира се. Нека продължим и коригираме нашия модел, за да включва това:
Забележете, че в тази версия на модела въведохме SSN поле за Children . Уникалната идентичност от деца вече се дефинира от техния собствен присъщ и уникален SSN . Тяхната самоличноствече не зависи на Parents маса. Въпреки че Parent_SSN полето все още препраща към SSN на Parents таблица, тя няма част от уникалната идентичност на детето, като по този начин родителите имат вне идентифиц връзка с техните деца и двете таблици вече могат да се считат за „силни“ самостоятелни обекти.
Като настрана, тази версия на модела има няколко предимства пред първата:
- Един родител вече може да има две или повече деца със същото име, докато целостта на обекта ограничението в предишния модел не би позволило това.
- Можете да разрешите
Parent_SSNполе да съдържаNULLза да отчетете събитието, че имате данни за детето, но не знаете кой е неговият/нейният родител.
И в двата горни модела Parents таблицата се счита за родителска таблица на Children маса. Въпреки това вне идентификация връзки като във втория модел, Parents е само родителска таблица в контекста на външния ключ Parent_SSN защото Parent_SSN препратки/зависи на SSN в Parents таблица, но не имат някаква роля в определянето на действителната самоличност на децата.
За да илюстрирате защо контекстът е важен, когато решавате кои таблици са родителски/подчинени таблици, разгледайте следния пример, включващ кръгова зависимост:
В този пример служителите и отделите са уникално идентифицирани чрез собствените си атрибути и не извличат никаква част от своята идентичност от други таблици.
Тук имаме две неидентифициращи взаимоотношения:служител работи за отдел (DeptNo в Employee таблица), а отделът се управлява от служител (ManagerSSN в Department таблица). Коя е родителската маса? ...Детска маса?
Зависи от контекста - за коя връзка с външен ключ говорите? Таблицата на отдела ще се счита за родителска таблица в контекста на DeptNo в Employee таблица, защото DeptNo е препращане/зависимо в Department маса.
Въпреки това таблицата Employee ще се счита за родителска таблица в контекста на ManagerSSN в Department таблица, защото ManagerSSN е препращане/зависимо на Employee таблица.
