Лучшая Схема для представления Баскетбольной Скобки NCAA

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

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

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

Так, для разработки базы данных для моделирования этого Вам действительно только нужны два объекта: Team и Game. Каждый Game имеет два внешних ключа, которые касаются другого Games. Имена не имеют значения, но мы смоделировали бы их как отдельные ключи для осуществления требования, чтобы каждая игра имела не больше, чем две предыдущих игры. Давайте назовем их leftGame и rightGame, оставаться с номенклатурой двоичного дерева. Точно так же нам нужно назвать ключ parentGame это отслеживает обратные отношения.

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

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

Так, полная схема была бы:

Game:
    winner: Team
    leftGame: Game
    rightGame: Game
    parentGame: Game
    other attributes as you see fit

Team:
    name
    other attributes as you see fit

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

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

{
  "round" : 1, //The final would be round 5, and I guess Alabama St. vs. Morehead would be 0
  "location" : "Dayton, OH",
  "division": "South",
  "teams" : ["UNC", "Radford"]  //A feature of Couch is that fields like teams don't need a fixed nuber of columns.
  "winner" : "UNC"  //Showing my bias
}

А более интересное или законченное приложение могло бы иметь данные для команд, рейтингов, и т.п. сохраненных где-нибудь также. Покрытия подхода John's, которые удят рыбу хорошо, это кажется. Я приветствую любые комментарии от людей, которые знают лучше на моих навыках Дивана.

Предложенная модель

Предложенная схема ER http://img257.imageshack.us/img257/1464/ncaaer.jpg

Таблица команды

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

Таблица MatchUp

Таблица "MatchUp" может использоваться для соединения команд в каждые из взлетов соответствия. Внешние ключи (FK1, FK2) "Команде" гарантируют, чтобы команды существовали, и первичный ключ по этим значениям гарантирует, что команды только подходятся друг против друга однажды.

Внешний ключ (FK4) к таблице "Team" от таблицы "MatchUp" запишет победителя. Логически победитель должен был бы быть одной из этих двух команд, участвующих в соответствии. Проверочное ограничение против первичного ключа могло гарантировать это.

После того как результат соответствия был убежден, что семя Victor's могло быть получено от таблицы команды для сравнения с другим Victor's для определения последующих взлетов соответствия. После выполнения так FK (FK3) к получающемуся совпадают, может быть записан во взлеты соответствия определения для изображения прогресса турнира (хотя эти данные могли, вероятно, быть получены в любое время).

Игровая таблица

Я также смоделировал, игры каждого Совпадают. Игра определяется соответствием, это - часть и порядковый номер на основе порядка, в котором это произошло во время соответствия. Игры имеют победителя от таблицы (FK2) команды. Счет мог быть зарегистрирован в этой таблице также.

Я создал маленькую систему со следующими таблицами:

Игры: GameId, TournId, RoundId, последовательность, дата, VisitorId, VisitorScore, HomeId, HomeScore, WinnerId, WinnerGameId, WinnerHome (бит)

Прогнозы: PredId, UserId, GameId, PredVisitorId, PredHomeId, PredWinnerId

Раунды: RoundId, TournId, RoundNum, Heading1, Heading2

Команды: TeamId, TournId, TeamName, семя, MoreInfo, URL

Турниры: TournId, TournDesc

Пользователи: TournId, UserName

WinnerGameId соединяет победителя игры к их следующей игре. WinnerHome сообщает, является ли победитель домом или посетителем той следующей игры. Кроме этого, я думаю, что это симпатично сам объяснительный.

4 таблицы:

Команда (команда, регион, семя)

Пользователь (UserId, электронная почта, blablabla)

Скобка (BracketId, UserId, точки)

Выберите (BracketId, GameId, команда, точки)

Каждая скобка, которую отправляет человек, будет иметь 63 строки в таблице Pick.
После того, как в каждую игру играют, Вы обновили бы таблицу выбора для выигрыша отдельных выборов. Поле точек в этой таблице будет пустым для игры, в которую еще не играют, 0 для неправильного выбора или положительного числа для корректного выбора. GameId является просто ключом, определяющим, где в том пользователи заключают в скобки этот выбор, идет (исключая: East_Round2_Game2, FinalFour_Game1).

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

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

Я использую ту же схему для всех моих баз данных.

t
--------
1 guid PK
2 guid FK
3 bit

Затем в моем коде:

select [2],[3] from t where [1] = @1

@1 идентификатор данных, я являюсь выбирающим. Затем, если [2] не является пустым, я выбираю снова, установка @1 к [2].

Это делает действительно легким смоделировать ситуацию, которую Вы отправили.