Моделиране на данни с нива на детайлност, някои от които липсват

Правя модел на данни за ролкова дерби лига, за да проследявам техните мачове. Проследявам неща като времена на обиколка, наказания на обиколка, наказания на период и наказания на мач.

Проблемът е, че в някои случаи ще имам само общите данни; Може да имам „дузпи на мач“ за един мач и „дузпи на период“ за друг. Така че на най-ниското ниво, за някои мачове, ще имам много подробни данни (дузпи за случай), а на най-високото ниво ще имам дузпи на мач.

Не съм сигурен как да моделирам/използвам това за отчитане, когато нямам висока детайлност за някои записи. Мислех за нещо подобно:

PenaltiesPerMatch MatchID PenaltyCount

PenaltiesPerPeriod MatchID PeriodID PenaltyCount

PenaltiesPerLap MatchID PeriodID LapID PenaltyCount

Но моето безпокойство е, че информацията от по-високо ниво може да бъде извлечена от по-ниско ниво. Дублирам ли записи (напр. попълвам запис за наказания за период с данни, които също са в наказания за обиколка, сумирани по период?) или поддържам уникални записи (не поставяйте наказания за период за данни, които вече имам в наказания на обиколка; изчислете го чрез сумиране на период).


sql datamodel
person Caveatrob    schedule 20.05.2009    source източник

Отговори (3)


arrow_upward
2
arrow_downward

Това, което бих направил, е да запиша информацията, която имате. За някои съвпадения го запишете с висока детайлност, за други с ниска детайлност.

Когато докладвате за мачовете:

  • Изчислете сумите на съвпадение за съвпадения с висока детайлност
  • Използвайте сумата за съвпадение от съвпаденията с ниска детайлност

Съхранявайте данни на най-ниското ниво на детайлност, което имате; изчислете по-високите нива на детайлност.

person Andomar    schedule 20.05.2009
comment
как бихте се справили със ситуацията, в която има само данни от високо ниво? В този случай изчислението няма да работи. - person Aaron M; 20.05.2009
comment
Изчислението превръща записите с висока детайлност (на тримесечие) в записи с ниска детайлност (на мач). Така че, ако всичко е с малко детайли, няма нужда от изчисление. - person Andomar; 21.05.2009
comment
Да, но OP посочва, че в някои случаи той може да няма данни от ниско ниво, а само данни от високо ниво. Ако той не винаги разполага с данни от най-ниското ниво, тогава той не може да изчисли високите нива на данни. - person Aaron M; 21.05.2009
comment
За всяко съвпадение имате данни от високо или ниско ниво. За първия вид съвпадение вече имате данните от високо ниво. За втория вид съвпадение можете да изчислите данните от високо ниво от данните от ниско ниво. Това е доста лесно да се направи в SQL. - person Andomar; 21.05.2009

arrow_upward
1
arrow_downward

Можете да запазите информацията в една таблица с NULL стойности, показващи, че нямате данни до това ниво. Не бихте могли да поставите първичен ключ върху това, така че ще имате нужда от сурогатен ключ, но трябва да можете да използвате уникално ограничение.

Например:

CREATE TABLE PenaltyCounts
(
    penalty_count_id INT NOT NULL,
    match_id         INT NOT NULL,
    period           TINYINT NULL CHECK (period BETWEEN 1 AND 3),
    lap              SMALLINT NULL,
    penalty_count    SMALLINT NOT NULL,
    CONSTRAINT PK_PenaltyCounts PRIMARY KEY NONCLUSTERED (penalty_count_id),
    CONSTRAINT UI_PenaltyCounts UNIQUE CLUSTERED (match_id, period, lap),
    CONSTRAINT CK_lap_needs_period CHECK (lap IS NULL OR period IS NOT NULL)
)

Един проблем с това, за който все още не виждам лесно решение, е как да наложа, че те могат да въвеждат наказания САМО на едно ниво. Например, те все още могат да направят това:

INSERT INTO PenaltyCounts (penalty_count_id, match_id, period, lap, penalty_count)
VALUES (1, 1, NULL, NULL, 5)
INSERT INTO PenaltyCounts (penalty_count_id, match_id, period, lap, penalty_count)
VALUES (2, 1, 1, NULL, 3)
INSERT INTO PenaltyCounts (penalty_count_id, match_id, period, lap, penalty_count)
VALUES (3, 1, 2, NULL, 2)

Предимството на това решение с една таблица е, че всичките ви статистики могат да бъдат намерени чрез запитване към една таблица и GROUP BY ще събере всичко добре.

Можете също да използвате метода на отделната таблица, но да поставите изгледи върху тях, за да съберете всичко заедно. Това все още разрешава проблема по-горе, но за поставяне на числа на множество нива.

person Tom H    schedule 20.05.2009

arrow_upward
0
arrow_downward

Мисля, че зависи каква информация е ценна за клиента. Ако искат да имат информацията по периоди, трябва да я включите като отделен запис. Дузпата по период и по мач трябва да бъдат разделени.

Винаги сте имали наказанието по информация за периода, тогава бихте могли да направите заявка, която сумира данните.

Ако вашите периоди винаги са фиксиран брой, тогава вероятно бихте могли просто да направите две колони в таблицата вместо нова таблица, за да съхранявате информацията за периода

person Aaron M    schedule 20.05.2009