Многие ко многим

Ваша бизнес-задача может быть неясной, поэтому давайте рассмотрим канонический пример книг и авторов. У одной книги может быть несколько авторов, и каждый автор потенциально может внести свой вклад в несколько книг. Итак, у нас есть классический Many-to-Many.

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

Книги и авторы

[книга]-1-----0-1-M-[авторство]-M-1-0------1-[автор]

Таблицы:

• book
  • pkey (primary key, the unique identifier of each book)
  • title
  • planned_publish_date
• authorship
  • pkey (optional, as some folks use the other two columns in a combined key as the primary key for this table)
  • fkey_book (содержит значение первичного ключа книги, над которой работает этот автор)
  • fkey_author (содержит значение первичного ключа автора, внесшего вклад в эту книгу)
• author
  • pkey (primary key, unique identifier of each author)
  • name
  • phone_number

Кардинальность здесь:

• A book can have any number of authorship rows related: cardinality of 0, 1, M (M meaning more than one).
  • A planned book can have zero rows in authorship because it is not yet associated with any author. Later, when an author is recruited, we add a row to authorship.
  • Книга с автором-одиночкой имеет одну authorship строку, связанную с одним автором.
  • Книга с парой авторов будет иметь две строки authorship, каждая из которых имеет внешний ключ, связанный со строкой author.
• Ditto for the author-authorship relationship: cardinality of 0, 1, M.
  • An author who has been recruited but not yet committed to any book will have a row in author table but no rows in authorship.
  • Автор, который работал только над одной книгой, будет иметь одну строку в authorship.
  • Плодовитый автор будет иметь много строк в authorship, по одной строке для каждой книги, в которой он/она участвовал.
• An authorship row must be assigned to a book AND assigned to an author: cardinality of 1 with book, and 1 with author.
  • We do not allow any authorship rows to be “orphaned”, to use the parent-child language some folks like me use in describing table relationships. In other words, on every authorship row, the pkey_book field must have a valid value, and the pkey_author field must have a valid value.

Время

Добавление измерения времени — непростая задача.

Один пример… Чтобы отследить период времени, когда контракт каждого автора на книгу начинается и заканчивается, мы должны добавить пару столбцов DATE в таблицу authorship под названием contract_start и contract_stop.

• authorship
  • pkey (primary key for this table)
  • fkey_book (содержит значение первичного ключа книги, над которой работает этот автор)
  • fkey_author (содержит значение первичного ключа автора, внесшего вклад в эту книгу)
  • contract_start (типа DATE)
  • contract_stop

Запрос действующие в настоящее время контракты сравнит сегодняшнюю дату как большую или равную contract_start И меньше contract_stop. Затем выполните join, чтобы получить название книги и имя автора.

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

Самолет-Полет-Местоположение

Что касается вашей проблемы с самолетом, я предполагаю, что под Send вы подразумеваете полет. Если да, то для ясности я бы назвал таблицу flight. Под местоположением, я полагаю, вы имеете в виду аэропорт. Опять же, для ясности я бы назвал таблицу airport.

Если это то, что вы имели в виду, то у вас есть та самая кардинальность, о которой говорилось выше.

• Самолет, присоединяющийся к флоту, может еще никогда не летать, летать один раз или летать во многие места. Итак, 0-1-М.
• Аэропорт может стать известен нашей системе до того, как мы полетим туда на каком-либо самолете, так что нулевых рейсов. Позже, один или несколько рядов рейсов, когда мы планируем один или несколько самолетов в этот аэропорт. Итак, 0-1-М.

В таблице flight есть столбцы для даты-времени отправления и длительности.

• flight
  • pkey (primary key for this table)
  • fkey_plane (содержит значение первичного ключа самолета, который будет доставлен в этот аэропорт в эту дату и время)
  • fkey_airport (содержит значение первичного ключа аэропорта, в который этот самолет вылетает в данную дату-время.)
  • departure (при взлете этого рейса типа TIMESTAMP WITH TIME ZONE)
  • duration (продолжительность данного полета, количество минут).

[самолет]-1-----0-1-M-[рейс]-M-1-0------1-[аэропорт]

Ваши бизнес-правила могут отличаться. Если вы планируете полет, но еще не назначили самолет, то у нас может быть строка flight без назначенного самолета. Таким образом, мощность 1 меняется на 0 or 1. Но не M, так как в одном конкретном полете никогда не участвует несколько самолетов. В случае этого бизнес-правила строка flight может быть потеряна из-за отсутствия родителя plane до тех пор, пока в конечном итоге не будет назначена конкретная плоскость.

[самолет]-1-0-----0-1-M-[рейс]-M-1-0------1-[аэропорт]