2009-12-13 4 views
1

Je configure une base de données de suivi des actifs. Les actifs varient entre les baies noires, PC, serveurs, moniteurs, haut-parleurs, claviers, souris, chaises, bureaux, cubicals, murs cubiques, imprimantes, réfrigérateurs, micro-ondes ... l'ensemble des choses. Cette gamme serait ma table Catégorie:Problèmes de conception de la base de données d'actifs

create table AssetManagement.zCategory(
    zCategoryId int identity primary key, 
    CategoryDescription varchar(15) unique not null 
    ) 

ordinateurs seraient facilement une catégorie, fabricant et le modèle, mais certains actifs (chaises ou autres) ne peuvent avoir un modèle. Certains peuvent seulement avoir un fabricant.

je crois que ce serait une bonne conception d'utiliser une bonne base de données pour appliquer les éléments suivants:

  • Si l'on connaît le fabricant d'un modèle,
    • il est impossible de stocker le même ID modèle ailleurs dans la base de données avec une autre catégorie ou le fabricant
  • un actif stocké dans la base de données doit avoir une catégorie
  • L'utilisation d'un identifiant pour une description de « inconnu » dans l'un des 3 serait mal à l'aise, mais il peut être nécessaire)

Ainsi, alors qu'un modèle pourrait avoir un fabricant connu, un atout pourrait avoir un modèle, ou fabricant, ou les deux, il devrait toujours avoir une catégorie.

Voici ce que je suis venu avec jusqu'à présent, et je pensais à l'aide d'un déclencheur pour appliquer ce que les clés étrangères directe ne

create table AssetManagement.zModel(
    zModelId int identity primary key, 
    zModelDescription varchar(15) unique not null, 
    zAssetCategoryId int not null references AssetManagement.zAssetCategory(zAssetCategoryId) 
) 


create table AssetManagement.zManufacturer(
    zManufacturerId int identity primary key, 
    zManufacturerDescription varchar(15) unique not null 
) 

create table AssetManagement.zProduct 
(
zProductId int identity primary key, 
zProductDescription varchar(35), 
zAssetCategoryId int references AssetManagement.zAssetCategory(zAssetCategoryId), 
zModelId int references AssetManagement.zModel(zModelId), 
zManufacturerId int references AssetManagement.zManufacturerId(zManufacturerId) 

) 


create table Assetmanagement.Asset(
    AssetId int identity primary key, 
    Tag varchar(15), 
    zProductId int not null references assetmanagement.zProduct, 
    zLocationId int references assetmanagement.zLocation(zLocationId), 
    EmployeeId int references assetmanagement.employee(employeeId), 
    PurchasedDate datetime, 
    PurchasedBy int references assetmanagement.employee(employeeId), 
    DisposalDate datetime, 
    Depreciated float, 
AddedBy int references assetmanagement.employee(employeeId), 
AddedDate datetime 
) 

Ou un raté le bateau et il y a une façon de concevoir cette c'est convienent (ayant modelID, manufacturerid et le type de produit tout sur la table d'actifs directement tout en appliquant l'unicité appropriée?

+1

Quel est le z dans tous les noms de champs? Arrête ça. – Joe

+0

c'est une pratique que j'ai prise au travail, les tables de recherche sont pré-fixées avec un z.Je l'ai porté dans le champ id de la table de recherche – Maslow

Répondre

4

je ferais cette façon.

  • Asset (id, m odel_id, asset_tag, created_date);
  • Modèle (id, id_atégorie, constructeur, modèle, description);
  • Catégorie (ID, nom);
  • Personne (id, titre, prénoms, nom, titre du poste, ...);
  • Affectation (id, asset_id, person_id, start_date, end_date, current_flag).

Fondamentalement, un actif est quelque chose avec une étiquette dessus. Il ne contient aucune information sur la catégorie, le fabricant ou le modèle. Vous êtes en train de dénommaliser vos données si vous le faites de cette façon. Il contient une clé étrangère au modèle, qui est cette information. Je vois le modèle et le fabricant comme n'étant rien d'autre que du texte libre, mais vos exigences peuvent transformer l'un ou l'autre ou les deux en tables dans certaines circonstances.

Vous pouvez stocker qui a l'actif dans la table des ressources, mais vous n'obtenez pas d'historique de cette façon (bien que cela puisse être fait avec un historique des ressources ou une table d'audit).

+0

ouais l'histoire allait provenir d'un tableau d'historique des biens – Maslow

+0

L'idée d'avoir 2 champs sur la table modèle: un pour le modèle réel s'il est connu, l'autre pour une vague description si pas connu l'a fait pour moi, merci. – Maslow

Questions connexes