Определение таблиц / первичных ключей

Question

Я проектирую базу данных для франчайзера. Мой уровень квалификации в лучшем случае средний (я просто работаю в офисе франчайзера). Эта база данных должна определять местоположение магазина и франчайзи. Так что я знаю, что мне понадобится стол "магазин" и стол "франчайзи". «Номер магазина» будет первичным ключом в таблице магазинов. Один франчайзи может иметь несколько магазинов. Я подумал, что могу просто назначить «ID франчайзи» в качестве первичного ключа в таблице франчайзи, чтобы привязать франчайзи к магазинам. Вот моя проблема: каждый магазин может принадлежать до 4 франчайзи. Так что я застрял на том, как определить все это. Я не уверен, что могу сделать несколько идентификаторов франчайзи, и даже если бы я мог, часто магазины принадлежат только 1 или 2 людям. Это означает, что много пустых полей. Кроме того, я не уверен, как все это соберется, когда мне нужно будет тянуть запросы. Любые предложения о наиболее логичном способе сделать это?

Answer 1

Вам нужна объединяющая таблица, создайте таблицу с именем franchisee_store с 2 полями идентификатора, 1 будет идентификатором магазина и один будет идентификатором франчайзи.

здесь хороший пример для вас.

Answer 2

Мне интересно, есть ли у кого-нибудь идеи о том, как применить правило «4 франчайзи на магазин» в хранилище данных Jet / ACE. Конечно, A2010 добавляет новые макросы данных на уровне таблицы, которые могут функционировать подобно триггерам, позволяя вам определить макрос данных для таблицы соединения, который может обеспечить выполнение этого бизнес-правила.

Но до A2010 не было никакого способа сделать это на уровне движка - вы должны поместить часть этой логики в само приложение.

Я думаю, что один из способов сделать это - добавить третий столбец в таблицу соединений, который является номером франчайзи. Как часть PK, это будет необходимо, и если вы добавите в него правило проверки, например, «Между 1 и 4». Это не будет автоматически увеличиваться, поэтому вам придется обрабатывать это в коде, но это предотвратит добавление записи, которая не соответствует правилу.

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

Answer 3

Ладно, значит, для магазинов у вас уже есть действительный первичный ключ - StoreNumber. Так что у вас в «магазине» стол будет что-то вроде

Store     StoreNumber INTEGER   PRIMARY KEY
          StoreName   STRING 
          ......

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

Franchisee  FranchiseeID    INTEGER  PRIMARY KEY
            FranchiseeName  STRING
            (other fields)

Чтобы присоединиться к этим двум, поскольку у вас может быть более одного владельца, вам нужен стол StoreOwner, что-то вроде этого:

StoreOwner    StoreNumber    INTEGER  FOREIGN KEY to "Store"
              FranchiseeID   INTEGER  FOREIGN KEY to "Franchisee"

Комбинация обоих полей (StoreNumber, FranchiseeID) будет вашим основным ключом в StoreOwner.

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

Answer 4

То, что вам нужно, это объединяющий стол «многие ко многим». Это правильный способ сделать это в третьей нормальной форме.

Пример:

franchisees:
    farnchisee_id
    other stuff
stores:
    store_id
    other stuff
franchisee_stores:
    frachisee_id
    store_id

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