2015-04-27 3 views
0

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

  • расположение
  • офис
  • школы
  • группа школ

ERD PK = первичный ключ, FK = внешний ключ

Допустим, мы хотим получить сведения о местоположении. Если в этом месте находится школа, мы хотим увидеть ее имя, количество студентов и название группы школ. Если это офис, мы хотим видеть только название офиса. С текущим дизайном это невозможно сделать в 1 запросе (насколько мне известно).

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

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

Спасибо заранее, Knarfi

ОТВЕТ: Я, наконец, нашел термин, который описывает мою проблему: Полиморфные ассоциации. Особенно this question дал мне хороший ответ.

ответ

1

Вы можете попробовать что-то вроде этого

SELECT location.*,school.*,office.* 
FROM location 
LEFT JOIN school ON school.locationID=location.locationID 
LEFT JOIN office ON office.locationID=location.locationID 

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

+0

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

1

Вы можете объединить школу и офис в одном Сущности, скажем: Организация со следующими атрибутами:

  • Organization_ID (PM)
  • Тип (1 = школа, 2 = Office)
  • LOCATION_ID (FK)
  • gROUP_ID (FK) (он может иметь значения только для школ, если вы не хотите, чтобы добавить группу информацию для офисов слишком бывшие: бухгалтерия, отдел продаж и т.д. в таблицах групп)
  • Имя
  • NumOfMembers (он может быть применен для обеих школ и офисов)

О ваш последний вопрос: "Хотя может быть способ, чтобы получить эти данные в 1 запрос я больше заинтересован в улучшая структуру базы данных. «Я должен сказать, что это не вопрос дизайна, а реализация. Помните, что очень плохой способ изменить дизайн в соответствии с вашими потребностями в реализации ...

В любом случае вы можете использовать ОДИН запрос в обоих случаях (ваш и мой), см. Ответы других людей. tIp: попытайтесь использовать представления ... они полезны в таких случаях.

+0

Я думал о множестве способов слияния таблиц, но проблема в том, что организационная структура не вписывается в дизайн. База данных предназначена для группы школ, поэтому организационная структура не подходит в базе данных. И вы правы в том, что это скорее вопрос реализации :) – Frank

1

Проект базы данных не ограничивает location тем, что связано с тем, что у него есть как school, так и office. (Может быть несколько школ и/или нескольких офисов.)

Существует несколько возможных способов получения информации, относящейся к location.

Вот один подход:

SELECT 'school' AS source 
    , s.name 
    , s.students 
    , g.name AS school_group_name 
    FROM location sl 
    JOIN school s 
    ON s.location_id = sl.id 
    LEFT 
    JOIN group_of_schools g 
    ON g.id = s.group_id 
UNION ALL 
SELECT 'office' AS source 
    , o.name 
    , NULL 
    , NULL 
    FROM location ol 
    JOIN office o 
    ON o.location_id = ol.id 

Если вам необходимо ограничить к определенному набору местоположения, вам нужно добавить WHERE положение на каждом SELECT.

Добавить ORDER BY, если вы хотите, чтобы строки возвращались в определенном порядке.

+0

Мне нравится подход, но меня больше интересует первый факт, который вы указали, прямо сейчас местом может быть школа и офис ... Вы знаете способ решить эту проблему? Я думаю, что это улучшение, которое я ищу! – Frank

+1

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

+1

Я рекомендую статью Скотта Амблера для обзора подходов отображения O/R для обработки «несоответствия импеданса» между таблицами hiearchy и реляционными базами данных OO: [** http: //www.agiledata.org/essays/mappingObjects .html **] (http://www.agiledata.org/essays/mappingObjects.html). (Например, в вашей текущей модели вы можете сделать 'location_id' уникальным в' school' и 'office', но есть никаких декларативных ограничений в базе данных, чтобы препятствовать тому, чтобы местоположение являлось как школой, так и офисом.) – spencer7593

Смежные вопросы