Дизайн базы данных: объясните эту схему

Question

Полное раскрытие ... Здесь яростно пытаюсь узнать больше о базах данных, поэтому я трачу время, а также пытался получить этот ответ из источника, но безрезультатно.

Эта схема есть у Барри Уильямса из базы данных и ответоввывешенный.

Схема клиентов и сборов

Я пытаюсь понять разделение таблиц адресов в этой схеме.Мне ясно, что таблица адресов содержит детали данного адреса.Таблицы Client_Addresses и Staff_Addresses - это то, что меня привлекает.

1) Я понимаю использование первичных внешних ключей, как показано, но я полагал, что при их использовании у вас нет резидентного первичного ключа в той же таблице (в данном случае date_address_from).Может кто-нибудь объяснить причину обоих и выразить словами, как это на самом деле работает?

2) Почему вы используете date_address_from в качестве первичного ключа вместо чего-то вроде client_address_id в качестве PK?Что если кто-то введет два адреса за один день, будут ли конфликты в его дизайне?Если так или нет, то что?

3) По линиям нормализации ... Поскольку и date_address_from, и date_address_to одинаковы в таблицах Client_Addresses и Staff_Addresses, если эти поля просто не будут включены в основную таблицу Address

Answer 1

Оценка

Сначала аудит, затем конкретные ответы.

1. Это не модель данных.Это не база данных.Это ведро рыбы, каждая рыба нарисована в виде прямоугольника, а там, где плавники одной рыбы пойманы в жабрах другой, есть линия.Есть масса дублирования, а также массы отсутствующих элементов.Это совершенно недостойно использования в качестве примера, чтобы узнать что-либо о проектировании базы данных из.

2. Нормализация вообще отсутствует;файлы очень неполные (см. ответ Майка, есть еще сотня подобных проблем).other_details и eg.s взбесили меня.Каждый элемент должен быть идентифицирован и сохранен: StreetNo, ApartmentNo, StreetName, StreetType и т. Д., А не line_1_number_street, который является группой.

   • Клиент и персонал должны быть нормализованы в таблицу Person со всеми идентифицированными элементами.

   • И да, если Клиент может быть либоЧеловек или Организация, тогда структура супертипа-подтипа необходима для правильной поддержки.

3. Итак, что это на самом деле, технически точные термины, представляет собой набор плоских файлов с описаниями для групп полей.Световые годы, удаленные от базы данных или реляционной.Не готов к оценке или проверке, не говоря уже о строительстве чего-либо с.В реляционной модели данных это будет приблизительно 35 нормализованных таблиц без дублированных столбцов.

4. У Барри есть (ждите его) более 500 «схем» в сети.В тот момент, когда вы попытаетесь использовать вторую «схему», вы обнаружите, что (а) они совершенно разные с точки зрения использования и цели (б) между ними нет никакой общности (в) скажем, в обоих случаях был файл клиента;это будут разные формы клиентских файлов.

   • Ему нужно сначала нормализовать всю единую "схему",

   • , а затем представить единую нормированную модель данных в 500 разделах или предметных областях.

   • Я написал ему об этом.Нет ответа.

5. Важно также отметить, что он использовал неузнаваемое соглашение о диаграммах.Проблема этих симпатичных интересных картинок заключается в том, что они передают некоторые вещи, но не передают важные вещи о базе данных или дизайне.Не удивительно, что ученик смущен;это не понятно опытным специалистам по базам данных.Существует причина, по которой существует стандарт для моделирования реляционных баз данных и для обозначения в моделях данных: они передают все детали и тонкости дизайна.

6. Есть много вещей, о которых Барри еще не читал: соглашения об именах;связи;мощность;и т.д., слишком много, чтобы перечислять.

Сеть полна мусора, каждый может "публиковать".Существуют миллионы хороших и плохо выглядящих «дизайнов», на которые не стоит смотреть.Или хуже, если вы посмотрите, вы узнаете совершенно неверные методы «дизайна».Что касается изучения баз данных и проектирования баз данных, вам лучше всего найти кого-то квалифицированного, с продемонстрированными способностями и учиться у него.

Ответ

1. Он использует составные ключи, не прописывая их.ПК для client_addresses составляет client_id, address_id, date_address_from).Это неплохой ключ, очевидно, он рассчитывает на запись адресов навсегда.

   • Идея сохранения адресов в отдельном файле - хорошая идея, но он не предоставил ни одного из полей, необходимых для хранения нормализованных адресов , поэтому «схема» будетв итоге полное дублирование адресов ;в этом случае он может удалить адреса и поместить строки обратно в файлы клиента и персонала вместе с их other_details, а также удалить три файла, которые не служат абсолютно никакой цели, кроме как занимают место на диске.

   Вы думаете об ассоциативных таблицах, которые разрешают отношения «многие ко многим» в базах данных. Да, там столбцы только PK двух родительских таблиц. Это не ассоциативные таблицы или файлы; они содержат поля данных.

2. Это не ПК, это третий элемент ПК.

   Представление о том, что лицо регистрируется по нескольким адресам в течение одного дня, не является разумным; просто посчитайте адрес, по которому они больше всего спали.

3. Другие ответили, что.

Не ожидайте выявить какие-либо доказательства базы данных или дизайна или нормализации на этой диаграмме.

Answer 2

3) По линиям нормализации ... Поскольку и date_address_from, и date_address_to одинаковы в таблицах Client_Addresses и Staff_Addresses, если эти поля просто не будут включены в основную таблицу Address?

Нет.Но вы нашли проблему.

Дизайнер решил, что клиенты и персонал - это две совершенно разные вещи.Под «совершенно иным» я подразумеваю, что у них нет общих признаков.

Это не правда, не так ли?И клиенты, и сотрудники имеют адреса.Я уверен, что у большинства из них тоже есть телефоны.

Представьте, что кто-то из сотрудников также является клиентом.Сколько мест хранится имя этого человека?Адрес этого человека?Слышите ли вы на заднем плане мистера Роджерса: «Можете ли вы написать« обновить аномалию »? ... Я знал, что вы могли бы».

Проблема в том, что дизайнер думал о клиентах и ​​сотрудниках как о разных типах.людей.Они не.«Клиент» описывает деловые отношения между поставщиком услуг (обычно это не розничный продавец) и клиентом, которым может быть либо человек, либо компания.«Персонал» описывает трудовые отношения между компанией и человеком.Не разные люди - разные виды отношений.

Вы видите, как это исправить?

Answer 3

1) В каждой из этих таблиц первичный ключ представляет собой составной ключ, состоящий из трех атрибутов: (staff_id, address_id, date_address_from) и (client_id, address_id, date_address_from).Предположительно это означает, что сопоставление клиентов / персонала с адресами, как ожидается, со временем изменится, и история этих изменений будет сохранена.

2) Нет очевидной причины для создания нового атрибута "id" в этихстолы.Составной ключ делает работу адекватно.Почему вы хотите создать один и тот же адрес дважды для одного и того же клиента в одну и ту же дату?Если вы это сделали, то это может быть причиной для изменения дизайна, но это кажется маловероятным требованием.

3) Нет. Очевидная цель состоит в том, что они являются применимыми датами для сопоставления адреса клиенту / персоналу.- даты не относятся к одному адресу.

Answer 4

Эти 2 дополнительные таблицы позволяют вам иметь историю адресов на одного человека.

Вы можете иметь их обоих в одной таблице, но, поскольку сотрудники и клиенты разделены, лучше их также разделить (b / c client id = 1, а идентификатор персонала = 1 нельзя использовать на одной таблице адреса).

не существует «единого» решения проблемы проектирования, вы можете использовать таблицу из 1 человека, а затем добавить столбец для разных сотрудников и клиентов. НО Основная идея заключается в том, что БД должна быть четкой, читаемой и эффективной, а не сохранять таблицы.

около 2 - ПК - это в сочетании , оба clientID, AddressID и from. так что если кто-то живет 6 месяцев в штатах, затем 6 месяцев в Израиле, а затем обратно в штаты по тому же адресу - вам нужно только 2 адреса в таблице адресов и 3 в client_address.

Идея составления метки from_Date как части ключа верна, хотя она не гарантирует целостность данных - так как вам также необходимо вручную проверить, нет ли перекрывающихся дат между записями одного и того же лица.

около 3 - нет (посмотрите на 2).

Answer 5

Что касается таблицы Staff_Addresses, первичный ключ для date_address_from в основном предотвращает запись с одним и тем же staff_id / address_id, введенным более одного раза. Теперь я не администратор баз данных, но мне нравятся мои PK, чтобы они были целыми числами или направляющими по соображениям производительности / более быстрой индексации. Если бы я сделал это, я бы создал новый столбец, скажем, Staff_Address_Id, сделал бы его столбцом PK и наложил уникальное ограничение на staff_id / address_id / date_address_from.

Что касается вашего последнего вопроса, таблица адресов - это действительно общая структура хранения адресов. Это не должно заботиться о диапазонах дат, в течение которых кто-то проживал там. Лучше оставить конкретные реализации адресов, таких как адреса клиентов / сотрудников.

Надеюсь, это немного поможет.

Answer 6

При просмотре модели данных, я думаю:

1) PF означает, что поле является частью первичного ключа таблицы и внешнего ключа с другой таблицей.

2) Точно так же первичным ключом Staff_Addresses является {staff_id, address_id, date_adderess_from}, а не просто date_adderess_from

3) То же, что 2)