Structure de base de données, un entrepôt de données relationnelle ou?

Question

Bonjour,

Im ayant des problèmes avec la façon dont ma base de données devrait être présenté et apprécierait quelques conseils. J'ai plusieurs tables (données de précipitations), chacune contenant les colonnes suivantes:

Date (DateTime), Value_of_rainfall (Float)

Chacune de ces tables sont un emplacement spécifique.

Il a été suggéré que je crée une autre table avec les colonnes suivantes:

LocationID (tinyInt), LocationName(char(6))

et l'insérer dans la première table une nouvelle colonne appelée LocationID (TINYINT).

Maintenant, la confusion est à moi est que les données en ce qui concerne i sont stockées dans les tables de données de données de précipitations. Son été suggéré que toutes les données de chaque emplacement sont contenues dans une table de données. L'analyse statistique im cherche à réaliser sur l'information est très (pour autant que je l'ai envisagé jusqu'ici) emplacement précis et ne vais pas avoir besoin d'interroger plusieurs endroits à la fois. Un mois de valeur de quelques données pour un emplacement = près de 3 millions de lignes et je cherche à mettre en place à long calculs en cours d'exécution sur les données. donc un entrepôt de données serait plus approprié? Si oui, quelqu'un pourrait me donner quelques conseils sur la façon dont je devrais étalez?

Merci pour votre temps.

Remarque: Im en utilisant SQL Server 2008

Answer 1

Il semble que vous voulez l'emplacement d'agrégats statistiques basées sur le temps de pluie. Une structure de base de données comme celle ci-dessous vous permettrait de le faire. La « source de données » pourrait être juste un nom de fichier, ou une indication à l'endroit où il est venu.

create table DimDataSource (
       DataSourceID      int identity (1,1) not null
       DataSourceDesc    nvarchar (100)  -- May need unicode for file names
)
go

alter table DimDataSource
  add constraint PK_DataSource
      primary key clustered (DataSourceID)
go

create table DimLocation (
       LocationID        int identity (1,1) not null
       LocationDesc      varchar (50)
)
go

alter table DimLocation
  add constraint PK_Location
      primary key clusterd (LocationID)
go

create table DimDate (
       DateID           smalldatetime not null  -- 'Date' is a reserved word
      ,MonthID          int not null
      ,MonthDesc        varchar (15)
      ,QuarterID        int not null
      ,QuarterDesc      varchar (15)
      ,YearID
)
go

alter table DimDate
  add constraint PK_Date
      primary key clustered (DateID)
go

create table DimTime (
       TimeID           time not null  -- 'Time' is a reserved word
      ,Hour             int not null
)
go

alter table DimTime
  add constraint PK_Time
      primary key clustered (TimeID)
go


-- If the table is <50GB, don't bother with partitioning, but put a clustered
-- index on DateID or LocationID and DateID, depending on how you normally expect
-- to query the data.

create table FactRainfall (
       RainfallID        int identity (1,1) not null -- May need a wider type if >4B rows.
                                                     -- SSAS likes an identity column for
                                                     -- incremental loads
      ,DataSourceID      int not null
      ,LocationID        int not null
      ,DateID            smalldatetime not null
      ,TimeID            time not null
      ,Rainfall          float
)
go

-- Add foreign keys as necessary

POPULATE les dimensions avec la liste appropriée des emplacements, des plages de dates, heure du jour au grain droit et un enregistrement de source de données par fichier. Ce tableau vous permettra également de mettre un cube sur le dessus, ou peut être aplati en vue, ce qui aidera les gens à l'aide d'outils comme Excel ou packages stats pour obtenir et utiliser les données.