Как исправить связь многие ко многим - Исправление недочетов и поиск решений вместе с Examum.ru

0 / 0 / 0

Регистрация: 17.11.2015

Сообщений: 7

17.11.2015, 21:17. Показов 9187. Ответов 6

Есть таблицы:
—Экзамены
-(PK)№ Экзамена
-Дата
-Студент
-Оценка
-Дисциплина (SK к Дисциплины.Название)
—Дисциплины
-(PK)Название
-Преподаватель (SK к Преподаватели.Табельный номер)
—Преподаватели
-(PK) Табельный номер
-Фамилия
-Имя
-Отчество
-Звание
-Кафедра

Как видно, в таблице Дисциплины нет первичного ключа, т.к. одну и ту же дисциплину могут вести 2 разных препода, и один и тот же препод может вести 2 разных дисциплины.
Прошу помочь и разделить таблицу Дисциплины на 2 разных таблицы так, чтобы PK сохранились как я указал.
Я думал над тем как это сделать и пришел лишь к идее сделать таблицу
—Дисциплины
-(PK) ID дисциплины
-Название дисциплины (SK к Квалификация преподавателей.Дисциплина)
—Квалификация преподавателей
-(PK) Дисциплина
— Преподаватели (SK к Преподаватели.Табельный номер (см. выше))
Как видите проблема осталась P.S. Вписывать множественные значения в одну строку не предлагать, так нельзя по заданию.

Programming Эксперт 94731 / 64177 / 26122 Регистрация: 12.04.2006 Сообщений: 116,782	17.11.2015, 21:17
6

26783 / 14462 / 3192

Регистрация: 28.04.2012

Сообщений: 15,782

17.11.2015, 21:53

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

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

2833 / 1375 / 215

Регистрация: 13.05.2011

Сообщений: 4,213

17.11.2015, 21:54

neon2, выложите вашу базу и на ней проэкспериментируем (пошупать надо ее).

шапоклякистка 8-го дня

3675 / 2235 / 391

Регистрация: 26.06.2015

Сообщений: 4,647

Записей в блоге: 1

17.11.2015, 22:15

Сообщение от mobile

ошибки неверного назначения препода на предмет, который он не преподает.

Не факт, что в реальной жизни это именно ошибка. Скажем, на мехмате экзамен по матану или линейной алгебре у первокурсников способен если не принимать, то как минимум ассистировать вообще любой сотрудник факультета. У нас примерно так и происходило.

Добавлено через 4 минуты
Скорее, дисциплины нужно группировать по смыслу, и делать проверку, что преподаватели взаимозаменяемы только в пределах группы дисциплин. Скажем, микологию и биологую преподаватели могут прнимать, заменяя друг друга, а физику твердых тел — уже нет.

26783 / 14462 / 3192

Регистрация: 28.04.2012

Сообщений: 15,782

17.11.2015, 22:37

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

шапоклякистка 8-го дня

3675 / 2235 / 391

Регистрация: 26.06.2015

Сообщений: 4,647

Записей в блоге: 1

18.11.2015, 08:24

Сообщение было отмечено alvk как решение

Решение

Упс. Да, увлеклась )))

Возвращаясь к заданию.

Сообщение от neon2

к идее сделать таблицу
—Дисциплины
-(PK) ID дисциплины
-Название дисциплины (SK к Квалификация преподавателей.Дисциплина)
—Квалификация преподавателей
-(PK) Дисциплина
— Преподаватели (SK к Преподаватели.Табельный номер (см. выше))
Как видите проблема осталась

Предлагаю не «квалификация преподавателей» это назвать, а «Курс лекций». При этом считать, что одна и та же дисциплина, читаемая разными преподавателями — это

разные

курсы лекций. Вводить первичный ключ «код курса лекций» и в таблице экзаменов делать связь именно с ним.

Добавлено через 2 минуты
Я имею в виду, вместо ключа от таблицы Дисциплина. Типа экзамен сдается не просто по Сопромату, а по Сопромату профессора Иванова.

0 / 0 / 0

Регистрация: 17.11.2015

Сообщений: 7

18.11.2015, 10:50

[ТС]

texnik-san, Спасибо, примерно так и сделал

Источник

Связь многие-ко-многим: пример в Access, в SQL. Как сделать связь многие-ко-многим?

Во всех СУБД (системах управления базами данных) имеется несколько типов отношений между таблицами. Среди них связь один-к-одному, один-к-многим, многие-к-одному (некоторые склонны отождествлять эти два типа в один) и связь многие-ко-многим. Пример последней, ее объяснение и применение в различных СУБД, таких как Access или SQL, будет рассмотрено в этой статье.

Определение

Связь многие-ко-многим определяется как соответствие любому из экземпляров одной из сущностей всех экземпляров другой. Другими словами, каждое поле из первой (второй) таблицы связано со всеми полями из второй (первой).

Представленная схема наглядно отображает суть данного отношения.

Когда может быть использована связь многие-ко-многим?

Пример связи многие-ко-многим — это студенческая группа и группа преподавателей. Каждый из студентов учится сразу у нескольких профессоров, которые, в свою очередь, читают лекции нескольким ученикам. На картинке показана разница между связью один-к-многим и многие-ко-многим.

Связь многие-ко-многим нередко необходима при составлении масштабных баз данных, мелкие показательные примеры обычно используются только в учебных целях, в реальной же практике получается так, что, чем больше сущностей в БД и больше взаимосвязей между ними — тем более вероятность частого обращения к отношению многие-ко-многим.

Как сделать связь многие-ко-многим?

Примеры рассматриваемого отношения еще будут добавляться по ходу статьи, однако важно не только понять, что оно собой представляет, но и то, каким образом можно его реализовать. Детали данного процесса напрямую зависят от выбранной для работы СУБД, в то время как принцип остается одним для всех.

Microsoft Access

Офисный программный продукт от «Майкрософт» известен на рынке ПО уже довольно продолжительное время. Он поставляется вместе с текстовым редактором Worfd, табличным процессором Excel и прочими, входящими в линейку «офиса». Можно Access (читается как «аксес», дословный перевод — «доступ») приобрести и отдельно от его «коллег». Рекомендуется купить, разумеется, лицензионный софт, но ни для кого не секрет, сколько пиратских репаков можно найти на просторах Сети, в виде обычных файлов или раздач торрентов. «Майкрософт Аксес» доступен даже в портативной сборке. Она, не требующая инсталляции и особых навыков работы с ПК, лучше всего подходит для выбора, если ПО не будет использоваться продолжительно и часто.

Из контекста ясно, что «Майкрософт Аксес» — это система управления базами данных. Причем одна из популярнейших. Она является реляционной, что значит, она основана на логической модели данных, которая в ходе своей работы обращается к теории множеств и логике первого порядка. Связь многие-ко-многим в Access (примеры будут даны в ходе объяснения) реализуется очень и очень просто. Рассмотрим ее.

Есть две таблицы..

Чтобы не придумывать ничего нового, возьмем уже указанный для того, чтобы разъяснить связь многие-ко-многим, пример про студенчество. Необходимо создать таблицу «Студенты» и таблицу «Преподаватели». Как в первой, так и во второй из них имеются первичные ключи. Для объединения экземпляров этих двух сущностей требуется также еще одна таблица, поля которой — ключи первой и второй таблиц.

Если рассмотреть иной пример: допустим, футболисты и команды ( с учетом того, что хотя бы один из футболистов играл за разные сборные, и каждая сборная имеет в своем составе одиннадцать игроков), суть построения связи не поменяется. Также будут нужны три таблицы. Из них «Футболисты» и «Команды» в качестве основных, и одна промежуточная.

Схема данных

Связи между таблицами в СУБД «Майкрософт Аксес» реализуются при помощи вкладки «Схема данных». На появившуюся панель добавляются все необходимые сущности (в нашем случае все три таблицы). Создание связи многие-ко-многим будет происходить при помощи двух отношений один-к-многих между главными («Студенты» и «Преподаватели») и промежуточной таблицы. Для этого необходимо соединить между собой соответствующие первичные ключи.

На иллюстрации выше показано, как выглядит вкладка «Схема данных» (Relathionships). Количество добавляемых на панель таблиц неограниченно. Расположение полностью регулируется пользователем.

Проектирование баз данных на SQL — задача сложнее, чем на «Аксес». Если майкрософтовский продукт полностью адаптирован под офисную среду, имеет огромный и, с каждым выпуском и обновлением все расширяемый, функционал, но в то же время и удобный для простого пользователя интерфейс, то SQL — это отдельный непроцедурный язык программирования, при помощи которого на разных платформах можно работать с базами данных. Известное ПО для данной задачи: Oracle MySQL и DB2 (популярное, но не единственное в своем роде). Несмотря на то, что у каждого из них есть свои тонкости и нюансы, язык SQL их «объединяет». Научившись работать хотя бы с одним из них, разобраться с другим будет гораздо проще.

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

Принцип создания связи многие-ко-многим

Длительное вступление могло несколько смутить и «напустить туману», но на самом деле принцип реализации связи остается прежним. Для того чтобы тип связи многие-ко-многим был воплощен на практике, не только в «Аксес», но и SQL, требуется изначально создать две базовые таблицы и одну — промежуточную. Аналогично дело обстоит и с ключами: основные сущности имеют главные поля, каждый из которых записывается в связующую таблицу. Что значит, что SQL-связь многие-ко-многим принципиально не отличается от «Аксеса».

Реализация связи

Для реализации связи многие-ко-многим в скриптах SQL используются внешние ключи (FOREIGN KEY) аналогичные исходным ключам в основных таблицах. Они записываются вместе со всеми полями при их создании и/или редактировании.

Роль связи многие-ко-многим

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

А это значит, что при составлении схемы данных (в «Аксесе») или написании скриптов (в «Оракл» или «ДиБиТу») будет присутствовать как минимум одна связь многие-ко-многим. Пример SQl, часто использующийся при обучении курса «Организации баз данных» — БД Кинга.

База данных Кинга

Эта учебная база данных представляет собой сведения о корпорации Кинга. Среди таблиц:

сотрудники фирмы — содержит в себе код сотрудника, его фамилию, имя и средний инициал (ориентированность на зарубежные имена), также код начальника и занимаемой сотрудником должности, дату его поступления в фирму, получаемый им оклад и предусмотренные комиссионные, код отдела;
отделы корпорации — среди полей таблицы есть код и название отдела, а также код его размещения;
места размещения отделов, которая предполагает внесение информации по коду места размещения и названия города;
должности в фирме — небольшая таблица с двумя полями кода должности и ее официального названия;
фирмы-покупатели — поля: код и название покупателя, адрес, город и штат, почтовый код и код региона, телефон, код обслуживающего покупателя менеджера, кредит для покупателя и комментарии (примечания и заметки);
договоры о продаже, содержащая в себе код и дату договора, код покупателя, дату поставки и общую сумму договора;
акты продаж — код акта и код договора, в который входит акт, код продукта, его цена, количество приобретенного и общая стоимость покупки;
товары — код и название продукта;
цены — код продукта, объявленная на него цена, минимально возможная цена,дата установления и дата отмены цены.

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

Масштабные же таблицы, такие как «сотрудники фирмы», «фирмы-покупатели», «договоры о продаже» и «акты продаж» связаны сразу с несколькими сущностями, причем с некоторыми — при помощи «посредников» отношением многие-ко-многим. Таблица «фирмы-покупатели» сама является посреднической, как таковая, ведь в ней есть многие поля, заимствованные из других таблиц и являющиеся внешними ключами. Кроме того, масштабность и взаимосвязь базы данных «Корпорации Кинга» такова, что все отношения неразрывно коррелируют между собой и влияют одно на другое. Разрушение хотя бы одного из них повлечет за собой деструкцию целостности всей БД.

Важные нюансы

При реализации связи многие-ко-многим, вне зависимости от того, какая используется СУБД, очень важно верно определить ключи, при помощи которых будет составляться отношение. Неправильно реализованная связь не выполнит своего основного предназначения, а именно — обеспечение целостности таблицы, и в результате, вместо ожидаемого комфорта, пользователь получит, напротив, неудобства и дополнительные проблемы, особенно проявляющиеся при заполнении таблиц и редактуры в них данных.

Аксесс связь многие ко многим

Примечание: Мы стараемся как можно оперативнее обеспечивать вас актуальными справочными материалами на вашем языке. Эта страница переведена автоматически, поэтому ее текст может содержать неточности и грамматические ошибки. Для нас важно, чтобы эта статья была вам полезна. Просим вас уделить пару секунд и сообщить, помогла ли она вам, с помощью кнопок внизу страницы. Для удобства также приводим ссылку на оригинал (на английском языке).

Что такое связь «многие-ко-многим»?

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

Связь «многие-ко-многим» предполагает возможность связи одного или нескольких элементов из одной таблицы с одним или несколькими элементами из другой таблицы. Примеры:

В таблице «Заказы» указаны заказы, сделанные разными клиентами из таблицы «Клиенты». Каждый клиент мог сделать несколько заказов.

В таблице «Продукты» указаны продаваемые товары, каждый из которых может фигурировать в нескольких заказах из таблицы «Заказы».

Каждый продукт может входить в один заказ как в одном, так и в нескольких экземплярах.

Например, в заказ Арины Ивановой № 1012 могут входить продукты № 12 и 15, а также пять продуктов № 30.

Создание связи «многие-ко-многим»

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

В рассмотренном ранее примере создавалась таблица «Сведения о заказах» с записями, в которых для каждого товара в нужном порядке указывались номер заказа из таблицы «Заказы» и код продукта из таблицы «Продукты». Первичный ключ для этой таблицы создавался путем объединения ключей из двух других таблиц.

Ниже рассмотрим пример, когда в заказ Арины Ивановой № 1012 входят продукты № 12, 15 и 30. Это значит, что записи в таблице «Сведения о заказах» выглядят следующим образом:

Арина заказала по одному продукту № 12 и 15, а также пять продуктов № 30. Создать другие строки с номером заказа 1012 и кодом продукта 30 нельзя, потому что поля «Номер заказа» и «Код продукта» вместе составляют первичный ключ, а первичные ключи должны быть уникальными. Вместо этого можно добавить в таблицу «Сведения о заказах» поле «Количество».

Создание промежуточной таблицы

Выберите Создание > Таблица.

Нажмите кнопку Сохранить .

Укажите описательное имя таблицы. Чтобы подчеркнуть назначение таблицы, можете включить в ее имя слова связующая или промежуточная.

Создание полей в промежуточной таблице

Столбец «Код» автоматически добавляется в Access в качестве первого. Измените имя этого поля на идентификатор вашей первой таблицы в связи «многие-ко-многим». Например, если первая таблица называется «Заказы», поле «Код» в ней переименовано в «Номер заказа», и его первичный ключ — число, измените имя поля «Код» в новой таблице на «Номер заказа», а в качестве типа данных выберите Числовой.

В режиме таблицы выберите заголовок столбца Код и введите новое имя поля.

Выберите переименованное поле.

На вкладке Поля в списке Тип данных выберите тип, как в соответствующем поле исходной таблицы, например Числовой или Короткий текст.

Щелкните надпись Щелкните для добавления и выберите тип данных, соответствующий первичному ключу во второй таблице. В заголовке столбца введите имя поля первичного ключа из второй таблицы, например «Код продукта».

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

Объединение полей для создания первичного ключа

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

Откройте промежуточную таблицу в режиме конструктора.

Выберите обе строки с идентификаторами. (Если вы следовали предыдущим указаниям, это будут две первые строки.)

Выберите Конструктор > Ключевое поле.
Рядом с обоими полями появится значок ключа.

Соединение трех таблиц для создания связи «многие-ко-многим»

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

После этого связи должны выглядеть следующим образом:

Вам нужны дополнительные возможности?

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

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

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

Чтобы создать отношение «многие ко многим», сначала нужно создать еще одну таблицу.

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

Промежуточная таблица также называется связующей.

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

Для этого нужно указать оба этих поля как первичный ключ связующей таблицы. Они становятся составным ключом.

Так как связующая таблица создается в режиме конструктора, открываем вкладку Создание и нажимаем кнопку Конструктор таблиц. Вот наша новая, пустая таблица.

Теперь откроем таблицы «Товары» и «Заказы».

Взглянем на первичные ключи обеих таблиц. В таблице «Товары» используется поле «ИД товара» с типом данных Счетчик.

Первичный ключ для таблицы «Заказы» называется «ИД заказа». Он также имеет тип данных Счетчик.

Теперь возвращаемся к связующей таблице, вводим имя поля «ИД товара», выбираем тип данных Числовой, вводим имя «ИД заказа» и снова выбираем тип данных Числовой.

Теперь выделим оба поля. Для этого наведите указатель на серый прямоугольник рядом с любым из этих полей и перетащите его.

Выделив оба поля, выбираем на ленте пункт Ключевое поле. Создается составной ключ для связующей таблицы.

Оба поля должны быть включены в составной ключ, чтобы у каждого заказа и всего, что в него входит, были уникальные идентификаторы.

Нажмите клавиши CTRL+S, чтобы сохранить связующую таблицу. Назовите ее «Сведения о заказе».

Теперь мы можем создать отношения. Для начала закройте все открытые таблицы. Выберите Работа с базами данных > Схема данных.

На вкладке Конструктор выберите элемент Добавление таблицы. Добавьте таблицы «Сведения о заказе», «Заказы» и «Товары». Закройте диалоговое окно.

Разместите таблицы так, чтобы связующая таблица «Сведения о заказе» была посередине. Перетащите поле «ИД заказа» из таблицы «Заказы» в связующую таблицу.

В диалоговом окне Изменение связей установите флажок Обеспечение целостности данных и нажмите кнопку Создать, чтобы создать отношение.

Выполните те же действия с полем «ИД товара». Установите флажок Обеспечение целостности данных, нажмите кнопку Создать — и все готово.

Нажмите клавиши CONTROL+S, чтобы сохранить изменения в схеме данных.

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

Аксесс связь многие ко многим

Pers.narod.ru. Обучение. Access VBA — редактируем связь многие-ко-многим и программно выполняем запрос с параметрами формы

Статья написана в учебных целях, хотя в ней есть и пара интересных неучебных нюансов.

Постановка проблемы: мы хотим динамически редактировать в Access связи между 2 таблицами, объединенными отношением «многие ко многим» (например, теги и слова, помеченные тегами, студенты и дисциплины, которые они посещают, или просто абстрактные «объекты» и «категории»). Думаю, понятно, что «многие ко многим» означает, что один объект может относиться к нескольким категориям и, наоборот, одной категории соответствует несколько объектов.

Классический способ реализации такой связи — промежуточная таблица, хранящая внешние ключи категорий и объектов и реализующая, таким образом, две связи «один ко многим», на которые мы разложили наше отношение:

Сама по себе реализация такого редактора в Access несложна, вот весь процесс.

1. Создаем новую базу данных и сохраняем ее.

2. В окне базы данных на вкладке «Таблицы» создаем в режиме конструктора 3 таблицы:

таблица «Категории» будет включать поле «Код категории», имеющее тип «Счетчик» и текстовое поле «Категория», служащее для описания; щелкнув правой кнопкой на поле «код», сделаем его ключевым:
таблица «Объекты» будет устроена аналогично: она включает ключевое поле-счетчик с именем «Код объекта» и текстовое поле «Объект», предназначенное для данных;
наконец, таблица «Связи» состоит из двух числовых полей, показанных ниже:

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

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

4. Закрыв и сохранив схему, вносим по несколько записей в таблицы «Категории» и «Объекты».

5. Формы для работы с категориями и объектами по отдельности или в связке «главная и подчиненная таблица» сделать легко. Для последнего, например, достаточно перейти на вкладку Формы, вызвать Мастер форм, добавить для формы все поля таблиц «Категории» и «Объекты», а на следующем шаге определить главную и починенную формы. Но нас интересует сейчас не это. Главное, что мы хотим сделать — спроектировать форму «Связи» для редактирования наших данных.

6. Вызываем Конструктор форм, получаем новую пустую форму. Если окна «Раздел: область данных» (на самом деле это окно свойств) нет на экране, вызываем его, выбрав в окне формы правой кнопкой мыши пункт меню Свойства.

7. В выпадающем списке окна свойств выбираем «Форма» и назначаем на вкладке Данные нашей форме источником данных таблицу «Связи».

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

Если мастера для этого или других элементов не вызываются, причин может быть 2: не нажата кнопка «Мастера» на Панели элементов или не установлены соответствующие компоненты Access.

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

9. Аналогичным образом создаем список для отображения объектов из таблицы «Объекты», а называться он будет «СписокОбъекты».

10. В принципе, все готово. Наша форма работает, в чем можно убедиться, открыв ее кнопкой Вид

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

11. Вернувшись в режим конструктора, добавим на свободное место кнопку и с помощью мастера «Создание кнопок» назначим ей действие «добавить запись» из категории действий «Обработка записей». Все остальное можно настроить по вкусу.

12. При выбранной кнопке в окне свойств перейдем на вкладку События и обратимся к коду сгенерированного нами обработчика:

13. Мы перепишем код сгенерированной Access процедуры так, чтобы он отслеживал ситуацию, когда в списках категорий и объектов ничего не выбрано, а также не давал повторно добавить уже существующую связь. Для последнего действия нам понадобиться выполнить из кода на VBA дополнительный запрос по извлечению выбранных на форме кода категории и кода объекта из таблицы «Связи». Если этот запрос вернет пустой результат, значит, такой связи еще нет и следует добавить запись. Сгенерировать такой запрос на вкладке «Запросы» и потом просто вызвать его, к сожалению, не получится. Дело в том, что Access не видит взятых из формы параметров запроса, если запрос выполняется программно. Ошибка, как правило, возникает со следующим текстом «Too few parameters. Expected Число» («Слишком мало параметров. Ожидалось Число»). Эта ошибка возникает, если команда или один из нижележащих запросов содержит обращения к формам или собственные параметры, — все эти обращения будут восприняты как параметры, которым не передано значение.

Почему так происходит? По этому поводу в справке Microsoft MSDN написано примерно следующее:
NOTE: В DAO Вы должны явно присвоить значение параметру. При использовании DoCmd.OpenQuery Вы этого делать не должны, т.к. DAO использует операции низкого уровня, что даёт Вам большую свободу в использовании параметров (т.е. Вы можете сами присвоить параметру значение переменной, а не использовать ссылку на форму), но Вы должны выполнить служебные действия, которые Access делает «за кулисами» при исполнении DoCmd. С другой стороны, DoCmd работает на более высоком уровне, чем DAO. Выполняя DoCmd, Microsoft Access делает некоторые предположения о том, как поступить с параметрами, и не дает Вам никакой свободы в этом отношении.

Попросту говоря, при выполнении запроса непосредственно из окна Access он выполняется с помощью движка JET, который, будучи встроен в Access, «знает» о наличии форм и пытается найти их поля и подставить значения. При выполении запроса из кода методом Execute или иным, запрос выполняется с помощью библиотеки DAO, которая, будучи внешней, ничего «не знает» о формах ACCESS, поэтому все недостающие значения считает неопределенными.

В Интернете можно встретить советы предварительно обработать все параметры процедурой вида

Однако, для работы этого кода нужно, во-первых, иметь подключенную DAO (в окне редактора Visual Basic при остановленной программе вызвать Tools, References (или Сервис, Ссылки), найти и включить в списке библиотеку Microsoft DAO 3.6 Object Library), во-вторых, работа кода все-таки не гарантируется и в этом случае.

Мы хотим обойтись стандартным кодом

однако, едва избавившись от ошибок с недостающимим параметрами, получим сообщение о нессответствии типов (type mismatch, ошибка с кодом 13)!

Вся проблема состоит в том, что объект RecordSet есть и в библиотеке DAO, и в используемой Access по умолчанию библиотеке ADODb! Таким образом, наличие прямой ссылки на DAO, как в показанной выше процедуре, не гарантирует работоспособность кода — может возникать куча заморочек, связанных с тем, какая библиотека подключена в данный момент и у какой выше приоритет.

Поискав (и не найдя) ответ по всему Интернету я догадался, наконец, описать RecordSet как Variant, то есть, без указания типа:

Все остальное было уже делом техники — программно получить в переменные нужные свойства полей, раз Access не будет обрабатывать их из внешнего запроса, сделать запрос для проверки того, нет ли уже в базе такой связи, затем либо разрешить добавление записи, либо выдать сообщение об ошибке. Вот, наконец, код процедуры, стоившей мне нескольких проведенных в матерщине часов:

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

Кстати, стандартные сообщения для кнопок навигации, генерируемые Access, можно заменить на свои более осмысленные, например, код

Это пример можно скачать и доделать, ведь область применения отношений «многие-ко-многим» так же широка, как сами эти отношения.

Связь многие-ко-многим: пример в Access, в SQL. Как сделать связь многие-ко-многим?

Определение

Представленная схема наглядно отображает суть данного отношения.

Когда может быть использована связь многие-ко-многим?

Как сделать связь многие-ко-многим?

Microsoft Access

Есть две таблицы..

Схема данных

Принцип создания связи многие-ко-многим

Реализация связи

Роль связи многие-ко-многим

База данных Кинга

Эта учебная база данных представляет собой сведения о корпорации Кинга. Среди таблиц:

сотрудники фирмы — содержит в себе код сотрудника, его фамилию, имя и средний инициал (ориентированность на зарубежные имена), также код начальника и занимаемой сотрудником должности, дату его поступления в фирму, получаемый им оклад и предусмотренные комиссионные, код отдела;
отделы корпорации — среди полей таблицы есть код и название отдела, а также код его размещения;
места размещения отделов, которая предполагает внесение информации по коду места размещения и названия города;
должности в фирме — небольшая таблица с двумя полями кода должности и ее официального названия;
фирмы-покупатели — поля: код и название покупателя, адрес, город и штат, почтовый код и код региона, телефон, код обслуживающего покупателя менеджера, кредит для покупателя и комментарии (примечания и заметки);
договоры о продаже, содержащая в себе код и дату договора, код покупателя, дату поставки и общую сумму договора;
акты продаж — код акта и код договора, в который входит акт, код продукта, его цена, количество приобретенного и общая стоимость покупки;
товары — код и название продукта;
цены — код продукта, объявленная на него цена, минимально возможная цена,дата установления и дата отмены цены.

Важные нюансы

Аксесс связь многие ко многим

Статья написана в учебных целях, хотя в ней есть и пара интересных неучебных нюансов.

Сама по себе реализация такого редактора в Access несложна, вот весь процесс.

1. Создаем новую базу данных и сохраняем ее.

2. В окне базы данных на вкладке «Таблицы» создаем в режиме конструктора 3 таблицы:

таблица «Категории» будет включать поле «Код категории», имеющее тип «Счетчик» и текстовое поле «Категория», служащее для описания; щелкнув правой кнопкой на поле «код», сделаем его ключевым:
таблица «Объекты» будет устроена аналогично: она включает ключевое поле-счетчик с именем «Код объекта» и текстовое поле «Объект», предназначенное для данных;
наконец, таблица «Связи» состоит из двух числовых полей, показанных ниже:

4. Закрыв и сохранив схему, вносим по несколько записей в таблицы «Категории» и «Объекты».

10. В принципе, все готово. Наша форма работает, в чем можно убедиться, открыв ее кнопкой Вид

В Интернете можно встретить советы предварительно обработать все параметры процедурой вида

Мы хотим обойтись стандартным кодом

Источник

Если
в концептуальной модели присутствуют
связи типа M:N («многие ко многим»),
то их
следует устранить путем определения
некоторой промежуточной сущности
(см. раздел 5.2.1). Связь типа M:N заменяется
двумя связями типа 1:М, устанавливаемыми
со вновь созданной сущностью. В качестве
примера рассмотрим связь типа M:N
Newspaper Advertises Property (Газета печатает
объявления об объектах, сдаваемых в
аренду), представленную на рис. 8.1, а. С
целью устранения связи Advertises
мы определяем промежуточную сущность
Advert и создаем две новых связи типа 1:М
(Lists и Advertisedin).
В результате связь Advertises
типа M:N будет заменена двумя связями
— Newspaper Lists
Advert и Property Advertisedin
Advert (как показано на рис. 8.1, б).

Обратите
внимание: сущность Advert показана как
слабая сущность, поскольку ее существование
зависит от сущностей-владельцев, а
именно от сущностей Newspaper и Property.

2. Удаление сложных связей

Сложной
называется связь, существующая между
тремя и больше типами сущностей (см.
раздел 5.1.3). Если в концептуальной модели
присутствует сложная связь, ее следует
устранить с помощью промежуточной
сущности. Сложная связь заменяется
необходимым количеством бинарных связей
типа 1:М, устанавливаемых со вновь
созданной сущностью. Например, тройная
связь Leases
(Сдает внаем), отражает отношения,
существующие между оформляющим аренду
работником компании, земельным
участком и арендатором — как показано
на рис. 8.2, а. Эту сложную связь можно
упростить путем введения новой сущности
и определения бинарных связей между
нею и каждой из исходных сущностей
сложной связи. В нашем примере связь
Leases
можно устранить посредством введения
новой слабой сущности с именем Lease
Agreement. Вновь созданная сущность будет
связана с исходными сущностями тремя
новыми бинарными связями:

S

taff
Organizes
Lease_Agreement,

Property
AssociatedWith
Lease Agreement и
Renter Holds
Lease_Agreement —
как показано
на рис.
8.2, б.

3. Удаление рекурсивных связей

Рекурсивными
называются такие связи, в которых
сущность некоторого типа взаимодействует
сама с собой (см. раздел
5.1.3). Если концептуальная
модель содержит рекурсивные связи,
они должны быть устранены посредством
определения некоторой промежуточной
сущности. Например, для отображения
ситуации, когда один из работников
руководит группой других работников,
может быть установлена рекурсивная
связь типа «один ко многим» (1:М)
Staff Supervises
Staff — как показано на рис.
8.3, а.

Рекурсивная
природа этой связи требует особого
подхода при работе с ней как на этапе
логического проектирования, так и на
этапе физической реализации базы
данных. Для упрощения данной рекурсивной
связи типа 1:М мы заменим ее вновь
созданной слабой сущностью Allocated
Staff и дополнительной связью типа 1:1 с
именем SupervisedBy —
как показано на рис. 8.3, б.

Удаление
рекурсивной связи типа M:N выполняется
так же, как и бинарных связей типа
M:N, описанных выше.

4. Удаление связей с атрибутами

Если
в концептуальной модели присутствуют
связи, имеющие собственные атрибуты,
они должны быть преобразованы путем
создания новой сущности (см. раздел
5.1.4). Например, рассмотрим ситуацию,
когда требуется фиксировать количество
рабочих часов, отработанных временным
персоналом каждого из отделений
предприятия (рис. 8.4, а). Связь Staff
WorksAt
Branch имеет атрибут с именем Hours_Worked
(Отработано часов). Преобразуем связь
VorksAt в
слабую сущность с именем Branch_Allocation,
которой назначим атрибут Hours_Worked, после
чего создадим две новых связи типа 1:М,
как показано на рис. 8.4, б.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Время на прочтение
6 мин

Количество просмотров 479K

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения customer_id в качестве внешнего ключа в таблице заказов.

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.

Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

Как опознать связь один-ко-многим?

Если у вас есть две сущности спросите себя:
1) Сколько объектов и B могут относится к объекту A?
2) Сколько объектов из A могут относиться к объекту из B?

Если на первый вопрос ответ – множество, а на второй – один (или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.

Примеры.

Некоторые примеры связи один-ко-многим:

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

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

8. Связь многие-ко-многим.

Связь многие-ко-многим – это связь, при которой множественным записям из одной таблицы (A) могут соответствовать множественные записи из другой (B). Примером такой связи может служить школа, где учителя обучают учащихся. В большинстве школ каждый учитель обучает многих учащихся, а каждый учащийся может обучаться несколькими учителями.

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

Обратите внимание, что при проектировании базы данных вы должны спросить себя не о том, существуют ли определенные связи в данный момент, а о том, возможно ли существование связей вообще, в перспективе. Если в настоящий момент все поставщики предоставляют множество видов пива, но каждый вид пива предоставляется только одним поставщиком, то вы можете подумать, что это связь один-ко-многим, но… Не торопитесь реализовывать связь один-ко-многим в этой ситуации. Существует высокая вероятность того, что в будущем два или более поставщиков будут поставлять один и тот же вид пива и когда это случится ваша база данных — со связью один-ко-многим между поставщиками и видами пива – не будет подготовлена к этому.

Создание связи многие-ко-многим.

Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – “источника” и одна соединительная таблица. Первичный ключ соединительной таблицы A_B – составной. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B.

Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей A и B должна быть уникальной в таблице A_B.

Пример проект базы данных ниже демонстрирует вам таблицы, которые могли бы существовать в связи многие-ко-многим между бельгийскими брендами пива и их поставщиками в Нидерландах. Обратите внимание, что все комбинации beer_id и distributor_id уникальны в соединительной таблице.

Таблицы “о пиве”.

Таблицы выше связывают поставщиков и пиво связью многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво ‘Gentse Tripel’ (157) поставляют Horeca Import NL (157, AC001) Jansen Horeca (157, AB899) и Petersen Drankenhandel (157, AC009). И vice versa, Petersen Drankenhandel является поставщиком 3 видов пива из таблицы, а именно: Gentse Tripel (157, AC009), Uilenspiegel (158, AC009) и Jupiler (163, AC009).

Еще обратите внимание, что в таблицах выше поля первичных ключей окрашены в синий цвет и имеют подчеркивание. В модели проекта базы данных первичные ключи обычно подчеркнуты. И снова обратите внимание, что соединительная таблица beer_distributor имеет первичный ключ, составленный из двух внешних ключей. Соединительная таблица всегда имеет составной первичный ключ.

Есть еще одна важная вещь на которую нужно знать. Связь многие-ко-многим состоит из двух связей один-ко-многим. Обе таблицы: поставщики пива и пиво – имеют связь один-ко-многим с соединительной таблицей.

Другой пример связи многие-ко-многим: заказ билетов в отеле.

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

Соединительная таблица связи многие-ко-многим имеет дополнительные поля.

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

Вы часто будете сталкиваться с такими ситуациями, когда совокупность двух сущностей будет являться новой сущностью.

9. Связь один-к-одному.

В связи один-к-одному каждый блок сущности A может быть ассоциирован с 0, 1 блоком сущности B. Наемный работник, например, обычно связан с одним офисом. Или пивной бренд может иметь только одну страну происхождения.

В одной таблице.

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

В отдельных таблицах.

В редких случаях связь один-к-одному моделируется используя две таблицы. Такой вариант иногда необходим, чтобы преодолеть ограничения РСУБД или с целью увеличения производительности (например, иногда — это вынесение поля с типом данных blob в отдельную таблицу для ускорения поиска по родительской таблице). Или порой вы можете решить, что вы хотите разделить две сущности в разные таблицы в то время, как они все еще имеют связь один-к-одному. Но обычно наличие двух таблиц в связи один-к-одному считается дурной практикой.

Примеры связи один-к-одному.

Люди и их паспорта. Каждый человек в стране имеет только один действующий паспорт и каждый паспорт принадлежит только одному человеку.

Проект реляционной базы данных – это коллекция таблиц, которые перелинковываются (связываются) первичными и внешними ключами. Реляционная модель данных включает в себя ряд правил, которые помогают вам создать верные связи между таблицами. Эти правила называются “нормальными формами”. В следующих частях я покажу как нормализовать вашу базу данных.

Какой же вид связи вам нужен?

Примеры связей таблиц на практике. Когда какие-то данные являются уникальными для конкретного объекта, например, человек и номера его паспортов, то имеем дело со связью один-ко-многим. Т.е. в одной таблице мы имеем список неких людей, а в другой таблице у нас есть перечисление номеров паспортов этого человека (напр., паспорт страны проживания и загранпаспорт). И эта комбинация данных уникальная для каждого человека. Т.е. у каждого человека может быть несколько номеров паспортов, но у каждого паспорта может быть только один владелец. Итого: нужны две таблицы.

А если есть некие данные, которые могу быть присвоены любому человеку, то имеем дело со связью многие-ко-многим. Например, есть таблица со списком людей и мы хотим хранить информацию о том, какие страны посетил каждый человек. В данном случае имеется две сущности: люди и страны. Любой человек может посетить любое количество стран равно, как и любая страна может быть посещена любым человеком. Т.е., в данном случае, страна не является уникальными данными для конкретного человека и может использоваться повторно.

В таких случаях использование связи многие-ко-многим с использованием трех таблиц и с хранением общей информации централизованно очень удобно. Ведь если общие данные меняются, то для того, чтобы информация в базе данных соответствовала действительности достаточно подправить ее только в одном месте, т.к. хранится она только в одном месте (таблице), в остальных таблицах имеются лишь ссылки на нее.

А когда у вас есть набор уникальных данных, которые имеют отношение только друг к другу, то храните все в одной таблице. Ваш выбор – связь один-к-одному. Например, у вас есть небольшая коллекция автомобилей и вы хотите хранить информацию о них (цвет, марка, год выпуска и пр.).

Источник

Многопользовательская картографическая таблица

Сделай это так.

    CREATE TABLE XtoY (
        # No surrogate id for this table
        x_id MEDIUMINT UNSIGNED NOT NULL,   
        y_id MEDIUMINT UNSIGNED NOT NULL,   
        # Include other fields specific to the 'relation'
        PRIMARY KEY(x_id, y_id),            
        INDEX      (y_id, x_id)             
    ) ENGINE=InnoDB;

Notes:

Отсутствие идентификатора AUTO_INCREMENT id для этой таблицы —Приведенный PK является ‘естественным’ PK;нет веской причины для суррогата.
«СРЕДНИЙ» — это напоминание о том, что все INT должны быть настолько маленькими, насколько это безопасно (меньше ⇒ быстрее). Конечно, объявление здесь должно совпадать с определением в таблице, с которой выполняется ссылка.
«UNSIGNED» — почти все INT могут быть объявлены неотрицательными.
«NOT NULL» — Ну, правда?
«InnoDB» — более эффективен, чем MyISAM, из-за способа кластеризации ПЕРВИЧНОГО КЛЮЧА с данными в InnoDB.
«ИНДЕКС (y_id, x_id)» — ПЕРВИЧНЫЙ КЛЮЧ позволяет эффективно двигаться в одном направлении; этот индекс делает другое направление эффективным. Не нужно говорить УНИКАЛЬНО; это потребовало бы дополнительных усилий для INSERT.
Во вторичном индексе,говоря JustINDEX(y_id),будет работать,потому что он неявно будет включать x_id.Но я бы предпочел сделать более очевидным,что я надеюсь на «охватывающий» индекс.

Чтобы условно ВСТАВИТЬ новые ссылки, используйте IODKU

Обратите внимание,что если бы в этой таблице был AUTO_INCREMENT,IODKU «сжигала бы» идентификаторы довольно быстро.

Подзапросы и СООН

Каждый подзапрос SELECT и каждый SELECT в UNION можно рассматривать отдельно для поиска оптимального INDEX.

Исключение:В «коррелированном» («зависимом»)подзапросе часть ГДЕ,зависящая от внешней таблицы,нелегко учесть в генерации ИНДЕКСа.(Выходите!)

JOINs

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

Оптимизатор обычно начинает с одной таблицы и извлекает из нее необходимые данные.Так как он находит полезную (т.е.соответствующую пункту WHERE,если таковая имеется)строку,он попадает в ‘следующую’ таблицу.Это называется NLJ («Nested Loop Join»).Процесс фильтрации и достижения следующей таблицы продолжается через остальные таблицы.

Оптимизатор обычно выбирает «первую» таблицу,основываясь на этих подсказках:

STRAIGHT_JOIN заставляет порядок следования таблиц.
Клаузула WHERE ограничивает то,какие строки необходимы (проиндексированные или нет).
Таблица «слева» в ЛЕВОМ СОБЩЕНИИ обычно располагается перед «правой» таблицей.(Посмотрев на определения таблиц,оптимизатор может решить,что «левая» таблица не имеет значения).
Нынешние ИНДЕКСы будут поощрять заказ.
etc.

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

Вы должны построить ИНДЕКС для «первой» таблицы на основе любых частей пунктов WHERE,GROUP BY и ORDER BY,которые имеют к ней отношение.Если в «GROUP/ORDER BY» упоминается другая таблица,вам следует проигнорировать этот пункт.

Вторая (и последующая)таблица будет составлена на основе положения о включении.(Вместо использования запятой,пожалуйста,напишите JOIN с ключевым словом JOIN и пунктом ON!).Кроме того,могут быть релевантные части пункта ГДЕ.GROUP/ORDER BY не должны рассматриваться в письменном виде как оптимальный INDEX для последующих таблиц.

PARTITIONing

УЧАСТНИК редко заменяет хороший ИНДЕКС.

РАЗДЕЛЕНИЕ ПО ДИАПАЗОНУ — это метод, который иногда бывает полезен, когда индексация оказывается недостаточно хорошей. В двухмерной ситуации, такой как близость в географическом смысле, одно измерение может частично обрабатываться путем отсечения разделов; тогда другое измерение может обрабатываться обычным индексом (предпочтительно ПЕРВИЧНЫМ КЛЮЧОМ). Это более подробно: Найдите 10 ближайших пиццерий .

FULLTEXT

FULLTEXT теперь реализован в InnoDB,а также в MyISAM.Он предоставляет возможность поиска «слов» в колонках TEXT.Это намного быстрее (когда применимо),чем колонка LIKE ‘%word%’.

    WHERE x = 1
      AND MATCH (...) AGAINST (...)

всегда(?)сначала использует индекс FULLTEXT.То есть весь алгоритм становится недействительным,когда один из AND является MATCH.

Признаки новичка

Никаких «составных» (так же известных как «составные»)индексов.
Нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет,нет.
Резервные индексы (особенно вопиющим является PRIMARY KEY(id),KEY(id)).
Большинство или все столбцы индивидуально индексируют («Но я все проиндексировал»).
«Commajoin» — то есть FROM a, b WHERE a.x=b.x вместо FROM a JOIN b ON a.x=b.x

Ускорение wp_postmeta

Опубликованная таблица (см.Википедию)

    CREATE TABLE wp_postmeta (
      meta_id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      post_id bigint(20) unsigned NOT NULL DEFAULT '0',
      meta_key varchar(255) DEFAULT NULL,
      meta_value longtext,
      PRIMARY KEY (meta_id),
      KEY post_id (post_id),
      KEY meta_key (meta_key)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

The problems:

AUTO_INCREMENT не дает никаких преимуществ;на самом деле он замедляет большинство запросов и сбивает с толку диск.
Гораздо лучше PRIMARY KEY(post_id,meta_key)—кластеризованный,обрабатывает обе части обычного JOIN.
BIGINT-это перебор,но это не может быть исправлено без изменения других таблиц.
VARCHAR(255)может быть проблемой в 5.6 с utf8mb4;см.обходные пути ниже.
Когда `meta_key` или `meta_value` когда-нибудь будет NULL?

The solutions:

    CREATE TABLE wp_postmeta (
        post_id BIGINT UNSIGNED NOT NULL,
        meta_key VARCHAR(255) NOT NULL,
        meta_value LONGTEXT NOT NULL,
        PRIMARY KEY(post_id, meta_key),
        INDEX(meta_key)
        ) ENGINE=InnoDB;

Postlog

Первоначальный пост:Март 2015 года;обновленный февраль 2016 года;добавить дату июня 2016 года;добавить пример WP мая 2017 года.

Подсказки в этом документе относятся к MySQL,MariaDB и Percona.

Решение

Связь многие-ко-многим: пример в Access, в SQL. Как сделать связь многие-ко-многим?

Определение

Когда может быть использована связь многие-ко-многим?

Как сделать связь многие-ко-многим?

Microsoft Access

Есть две таблицы..

Схема данных

Принцип создания связи многие-ко-многим

Реализация связи

Роль связи многие-ко-многим

База данных Кинга

Важные нюансы

Аксесс связь многие ко многим

Что такое связь «многие-ко-многим»?

Создание связи «многие-ко-многим»

Создание промежуточной таблицы

Создание полей в промежуточной таблице

Объединение полей для создания первичного ключа

Соединение трех таблиц для создания связи «многие-ко-многим»

Вам нужны дополнительные возможности?

Аксесс связь многие ко многим

Связь многие-ко-многим: пример в Access, в SQL. Как сделать связь многие-ко-многим?

Определение

Когда может быть использована связь многие-ко-многим?

Как сделать связь многие-ко-многим?

Microsoft Access

Есть две таблицы..

Схема данных

Принцип создания связи многие-ко-многим

Реализация связи

Роль связи многие-ко-многим

База данных Кинга

Важные нюансы

Аксесс связь многие ко многим

2. Удаление сложных связей

3. Удаление рекурсивных связей

4. Удаление связей с атрибутами

7. Связь один-ко-многим.

Как опознать связь один-ко-многим?

Примеры.

8. Связь многие-ко-многим.

Создание связи многие-ко-многим.

Таблицы “о пиве”.

Другой пример связи многие-ко-многим: заказ билетов в отеле.

9. Связь один-к-одному.

В одной таблице.

В отдельных таблицах.

Примеры связи один-к-одному.

Какой же вид связи вам нужен?

Многопользовательская картографическая таблица

Подзапросы и СООН

JOINs

PARTITIONing

FULLTEXT

Признаки новичка

Ускорение wp_postmeta

Postlog

See also

MariaDB 10.9

MariaDB

10.9