Quand à Dénormaliser une Conception de Base de données

Je sais que normalis(z)ation a été largement discuté sur un Débordement de Pile. J'ai lu beaucoup de discussions antérieures. J'ai quelques questions supplémentaires si.

Je suis en train de travailler sur un système d'héritage avec au moins 100 tables. La base de données est a quelques des nations unies normalisés en fonction de la structure, des tableaux qui contiennent une variété de données disparates, et d'autres problèmes. J'ai été donné la tâche d'essayer de l'améliorer. Je ne peux pas commencer à nouveau, mais besoin de modifier le schéma existant.

Dans le passé, j'ai toujours essayé de conception de bases de données normalisé. Maintenant, les questions. Un développeur senior a suggéré que, dans certains cas, nous ne pouvons normaliser:

1) Avec les données temporelles. Par exemple, une facture est créée que des liens vers d'un produit. Si un client demande une copie de cette facture, un an plus tard, nous devons être en mesure de produire une copie exacte de l'original. Que faire si le prix du produit, le nom ou la description ont été mises à jour? Les seniors gars ont suggéré que le prix du produit et d'autres informations doivent être copiées dans la table de facture. Je pense peut-être que nous devrions avoir une autre table comme productPrice qui a un champ de date afin que nous puissions suivre les changements de prix au fil du temps. Il nous faudrait la même chose pour la description du produit et le nom, je suppose? Semble compliqué. Qu'en pensez-vous?

2) La base de données est un système de comptabilité. Je ne suis pas très familier avec la comptabilité. Au moment sommaire de certaines données sont obtenues et stockées dans la base de données. Par exemple, les ventes totales de l'année. Mon associé senior, a déclaré que les comptables pour vérifier les choses sont correctes en comparant cette valeur avec des données qui est en fait calculée à partir des factures, etc, pour leur donner de la confiance que l'application fonctionne correctement. Il a dit que pour le moment, par exemple, on peut savoir si quelqu'un a supprimé une facture de l'année dernière, à tort, parce que les totaux ne sera pas la même. Il a également souligné qu'il pourrait être assez lent à calculer les totaux à la volée. Bien sûr, j'ai dit que les données ne doivent pas être dupliqués et doit toujours être calculée en cas de besoin. J'ai suggéré que nous pourrions utiliser SQL Reporting Services ou une autre solution qui permettra de générer ces rapports pour la nuit et les mettre en cache. De toute façon, il n'est pas convaincu. Tous les commentaires sur cette?

Merci beaucoup 🙂

Cheers

Marque

MODIFIER

Merci pour les excellentes réponses. C'est dommage, je ne peux drapeau de l'un à la réponse, car il ya beaucoup de bonnes suggestions ici.

Reporting Services est une très bonne solution pour le rapport de synthèse cacher le problème. C'est ce que SSRS a été conçu pour.
Vous pouvez demander les détails à propos de 2) point sous une autre question. La normalisation est assez compliqué. Et puis vous avez besoin de définir un peu mieux, par exemple - vous prétendre qu'il affirme qu'il peut être lent, mais, en même temps qu'il allait l'utiliser pour vérifier si quelqu'un a supprimé quelque chose (et de vous fournir cela comme un exemple pour l'application fonctionne correctement - et à moins que vous voulez dire que la sécurité est mise en œuvre correctement, votre exemple suppose en fait que l'application fonctionne correctement). Donc, comme je l'ai dit - de mieux faire que le point 2 un peu plus claire et moins contradictoire.
Supérieurs de votre collègue est un développeur, pas un modeleur de données. Vous êtes mieux de commencer à partir de zéro, avec eux. La Normalisation est compliqué uniquement à ceux qui ne lisent pas de livres, et de faire passer leur "connaissance" de la les amateurs au wiki.

InformationsquelleAutor Mark Evans | 2010-11-29

43

Supérieurs de votre collègue est un développeur, pas un modeleur de données. Vous êtes mieux de commencer à partir de zéro, sans eux. La Normalisation est compliqué uniquement à ceux qui ne lisent pas de livres, et de faire passer leur "connaissance" de la les amateurs au wiki. Il est assez juste qu'il vous fait penser, mais certaines questions sont absurdes.

Vos numéros:
1. Vous avez besoin pour apprécier les différences entre les résultats réels de données en ligne, et les données historiques; ensuite, la différence entre simplement historique et les besoins en matière d'archives. Tous sont en droit spécifique à l'exigence de l'entreprise, et le mal pour tous les autres, il n'y a pas de droit universel et le mal.
  - pourquoi il n'y a pas de papier de la copie de la facture ? Dans la plupart des pays qui serait un cadre juridique et fiscal exigence, quelle est exactement la difficulté de pêche le vieux facture ?
  - où la base de données a la exigence de stockage fermé les factures, c'est sûr que, dès que la facture est fermé, vous avez besoin d'une méthode de capture de l'information.
  - ProductPrice (en fait, je dirais que c'est ProductDate) est une bonne idée, mais peut-être pas nécessaire. Mais vous avez raison, vous avez besoin pour évaluer la validité des données, dans le contexte de l'ensemble de la base de données.
  - Je ne vois pas comment copier le produit du prix de la facture de la table de l'aide (ne sont pas là de nombreux éléments de ligne ?)
  - dans des bases de données modernes, où la copie de la facture est nécessaire pour être régurgité, le clos de la Facture est également stockée dans une forme différente, par exemple, XML. Un client enregistre les fichiers Pdf comme des Gouttes. Donc, il n'y a pas de déconner avec ce que le prix du produit était il y a cinq ans. Mais la facture de base de données est en ligne et à jour, même pour les factures; vous ne pouvez pas recalculer l'ancienne facture en utilisant les prix actuels.
  - certaines personnes utilisent un archive_invoice table, mais qui a des problèmes parce que maintenant chaque segment de code ou de l'utilisateur de l'outil de rapport de a à regarder à deux endroits (à noter que ces jours, certains utilisateurs à comprendre les bases de données mieux que la plupart des développeurs)
  - De toute façon, c'est-à toutes les discussions, pour votre compréhension. Aucun des bases de données que j'ai écrit dans les 30 dernières années a jamais eu ce genre de problème, et l'ensemble de leur conformité avec les dispositions légales et les obligations en matière fiscale.
    
    La base de données sert de courant et à des fins d'archivage à partir d'un ensemble de tables (pas de "archive" tables
    
    Une fois qu'une Facture est créée, c'est un document juridique, et ne peut pas être modifié ou supprimé (il peut être inversé ou partiellement attribuée par une nouvelle Facture, avec des valeurs négatives). Ils sont marqués IsIssued/IsPaid/Etc
    
    Products ne peuvent pas être supprimés, ils peuvent être marqués IsObsolete
    
    Il y a des tables séparées pour les InvoiceHeader et InvoiceItem
    
    InvoiceItem a FKs à la fois InvoiceHeader et Product
    
    pour de nombreuses raisons (pas seulement ceux que vous mentionnez), le InvoiceItem ligne contient le NumUnits; ProductPrice; TaxAmount; ExtendedPrice. Bien sûr, cela ressemble à une "dénormalisation" mais il n'est pas, parce que les prix, les taux d'imposition, etc, sont sujettes à changement. Mais le plus important, l'obligation légale est que nous pouvons reproduire le vieux facture sur demande.
    
    (où elle peut être reproduite à partir des dossiers sur papier, ce n'est pas nécessaire)
    
    la InvoiceTotalAmount est un dérivé de la colonne, juste SUM() de la InvoiceItems
    
    .
2. Que c'est de la foutaise. Les systèmes comptables et les comptables ne sont pas "travailler" comme ça.
  - Si c'est un véritable système de comptabilité, alors il aura JournalEntries, ou "à double entrée"; c'est ce qui est qualifié de compte est nécessaire pour l'utiliser (par la loi).
    
    Double Entrée ne signifie pas entrée en double; il signifie toute transaction financière (une quantité) doit disposer d'un compte source et cible compte qu'il est appliqué; il n'y a pas de "dénormalisation" ou de duplication. Dans une de services bancaires de base de données, parce que les transactions financières sont contre une seule des comptes, qui est généralement traduit comme deux transactions financières (lignes) dans un délai d'un Db Transaction. Ordinaire de la base de données commerciale, les contraintes sont utilisées pour s'assurer qu'il y a deux "côtés" pour chaque transaction financière.
    
    .
  - Assurer que les Factures ne sont pas deleteable est une question distincte, de la sécurité, etc. si quelqu'un est paranoïaque à propos de choses étant supprimé à partir de leur base de données, et leur base de données n'a pas été garanti par une personne qualifiée, alors qu'ils ont plus de et les différents problèmes qui n'ont rien à voir avec cette question. Obtenir un audit de sécurité, et de faire tout ce qu'ils vous disent.
  - Il y a quelques personnes sur ce site qui pense que le wiki est un endroit que vous pouvez apprendre quelque chose. Il n'est pas. C'est un cloaque de "définitions", écrit par des amateurs, et les "définitions" sont constamment modifiées par d'autres amateurs. Aucune définition précise de ce que vous pouvez compter sur. Alors ne vous inquiétez pas à propos de ce que le wiki dit ou ce que les gens disent wiki dit, du moment qu'ils mentionnent wiki, vous savez leur "connaissance" est venue de la lecture de pas de qualification; et de ce qu'ils lisent est en constante évolution cloaque. Ils prévisible disputent à propos de "définitions" car ils n'ont pas l'expérience réelle; le connu simplement le travail
  - Normalisé de la base de données est toujours beaucoup plus rapide que Unnormalised base de données. Il est donc très important de comprendre ce que la Normalisation et Denormalisaion est, et ce qu'il ne l'est pas. Le processus est grandement entravée lorsque les gens ont des fluides et des amateurs de "définitions", c'est simplement conduit à la confusion et perte de temps "discussions". Lorsque vous aurez résolu les définitions, vous pouvez éviter tout cela, et tout simplement le travail.
  - Les tableaux sont tout à fait normal, pour gagner du temps et de puissance de traitement, de recalculer info qui ne change pas, par exemple: les totaux depuis un an pour chaque année, mais cette année; DMT totaux pour chaque mois de cette année, mais pas ce mois-ci. "Toujours le recalcul des données" est un peu idiot quand (a) l'info est très grand et (b) ne change pas. Calculer pour le mois en cours seulement
    
    Dans les systèmes bancaires (en millions de transactions par jour), à EndOfDay, nous calculer et de stocker Quotidienne ainsi. Ces sont remplacés par les cinq derniers jours, parce que Audiitors sont à faire des changements, et JournalEntries contre les transactions financières pour les 5 derniers jours sont autorisés.
    
    non-bancaire en général, les systèmes n'ont pas besoin de totaux journaliers
    
    .
  - Tableaux de synthèse ne sont pas une "dénormalisation" (sauf dans les yeux de ceux qui ont juste appris à propos de la "normalisation" de leur magie, toujours changeant fluide "source"; ou en tant que non-praticiens, qui s'appliquent simple en noir ou blanc les règles de tout). Là encore, la définition n'est pas soutenu en l'espèce; il a simplement ne s'applique pas de tableaux de Synthèse.
  - Tableaux de synthèse n'affectent pas l'intégrité des données (en supposant bien sûr que les données qu'ils étaient en provenance d'faisait partie intégrante).
  - Les tableaux de synthèse sont un plus à la base de données, qui ne sont pas tenus d'avoir les mêmes contraintes que la base de données. Il y a essentiellement des rapports de tableaux ou de tables d'entrepôt de données, plutôt que des tables de base de données.
  - Il n'y a pas de mise à Jour des Anomalies (qui est une définition stricte) liées à des tableaux récapitulatifs. Vous ne pouvez pas modifier ou supprimer une facture de l'année dernière. Mise à jour des Anomalies s'appliquent à vrai Denormalised ou Unnormalised des données actuelles.
- Wow - c'est ce que j'appelle une réponse! Je ne suis pas heureux de payer votre taux horaire pour ce genre de choses. Il est en or massif. Je sens que je commence à vraiment comprendre tout cela maintenant. Grâce PerformanceDBA 🙂
- Merci! Pour le changement (inattendu!) et le compliment. Vous avez raison, toute personne postant sur ne peuvent DONC pas se permettre mon taux horaire. N'hésitez pas à poster de nouvelles questions, si je l'attrape, je vais répondre.
- Généralement, l'ensemble de votre réponse est très bon et très utile; il y a quelques articles qui sont contestables, mais il en est un qui est complètement inutile et le plus souvent fausses. C'est un article sur wiki - le montant de contradictions, vous avez réussi à le pack de là est tout à fait intéressant - je vais sortir un argument: "Leurs "connaissances" vient de la lecture et pas de qualification.". Il montre que vous pouvez utiliser la lecture comme un argument en faveur inférieure de la connaissance. (!) (Je ne vais pas défendre wiki en détail; c'est utile pour certaines fins, et il peut être de qualité inférieure pour les autres; tant qu'elle cite des références...
- ..et ne pas omettre les principaux domaines d'un concept, c'est surtout le utile). Vous avez tort de généraliser concernant les auteurs et les processus. Vous avez tort de généraliser à propos de gens qui cite wikipedia, par exemple, je cite wikipedia, car il est disponible pour tout le monde, non pas parce qu'elle a été la principale source de ma connaissance; je le cite parce qu'il fait généralement référence à d'autres œuvres, de sorte qu'il est facile de suivre les réclamations. Aussi, j'essaie d'évaluer ce que wikipédia devis et la qualité générale. J'espère que ces remarques vous permettra de voir et de corriger la subjectivité que vous avez employées sur ce point.
- Veuillez identifier les techniques de base, vos qualifications et votre expérience, sur laquelle vous faites état, telles que "vous avez tort ...". Sinon, les états sont verbeux, mais vide.
- base dans ce cas est de la logique pure. Vous avez tort de généraliser: "Il y a quelques personnes sur ce site qui pense que le wiki est un endroit que vous pouvez apprendre quelque chose. Il n'est pas." Cette "conclusion" n'a aucun fondement dans la logique, c'est une opinion. Un que je peux essayer(!) pour réfuter comme ceci: 1) lecture de en.wikipedia.org/wiki/Ad_hominem 2) si vous acceptez les références et la qualité de cet article, vous apprenez quelque chose* et qui serait en contradiction avec votre propre déclaration. * = argumentum ad hominem est logique (et rhétorique) *erreur*(!) - qui n'a pas sa place dans les discussions techniques.
- La plupart de cette réponse, c'est utile, mais je suis fortement en désaccord avec l'affirmation que "Normalisé de la base de données est toujours beaucoup plus rapide que Unnormalised de la base de données". C'est manifestement faux, même si je n'ai pas la harpe sur l'utilisation de "toujours". Il existe de nombreux scénarios où sélective, cohérente dénormalisation d'une base de données peut être une amélioration de la performance. Si vous pouvez savoir à l'avance ce complexe, chronophage interroge une base de données recevrez, vous pouvez précalculer les résultats de ces requêtes, par exemple, le remplacement d'un 14-table de jointure avec une table qui contient déjà les données nécessaires.
- -1 être d'accord avec @ChrisJohnson commentaire ci-dessus. Trop extrapolation abusive et large hypothèse, manque de la plus fine compréhension des complexités impliquées, ainsi que gonflé attitude qui est à un peu plus de place ici. Et oh, la plupart des DW sont dénormalisée, il y a une raison et de la place pour elle.
- Downvote pour cette déclaration: "Vous êtes mieux de commencer à partir de zéro, sans eux. La Normalisation est compliqué uniquement à ceux qui ne lisent pas de livres, et de faire passer leur "connaissance" de la les amateurs au wiki.", sinon ok. Certains d'entre nous n'avez pas besoin de livres...
InformationsquelleAutor PerformanceDBA
9

1) C'est une archive. Tout ce qui est en elle ne doit jamais être mis à jour. J'irais avec le haut du mec suggestion et ont que la facture de la table autonome. Peut-être utiliser un blob pour la facture elle-même qui contient markup language?

2) Reporting services, un entrepôt, un tableau qui est le point de déclenchement de mise à jour, quelque chose de vous construire par le script à chaque fois que... tous ces bien, je pense. Il est en effet idéal pour être normalisée, mais il n'est pas toujours rapide. J'ai une bonne taille de soins de santé de base de données, je gère qui est entièrement normalisée... et ensuite on a une série de tables normalisées avec roulé équations et souvent tiré des champs. Presque tout fonctionne de que de-normalisée ensemble, c'est juste plus rapide ajouter à ceux-ci avec un déclencheur quand les fichiers sont chargés de garder l'avoir à tirer de diverses tables de chaque fois que je veux regarder une 100 000 rapport.
- Grand commentaire de l'Autocratie - merci! 1) Ainsi, la table de facture n'aurait pas un rapport avec les produits de la table? C'est ce que tu veux dire? 2) Si les totaux sont mis à jour avec un seuil de déclenchement ne serait pas que faire de toute insertion qui active le déclencheur très lent? Désolé, mais je suis assez ignorant de cette approche. Cheers, Marque.
- Vous pourrait ajouter une version dimension de la table produit et de le rendre insérer seule et puis de référence unique rpoduct version dans les factures. Conceptuellement, cela est le plus propre conception, cependant, même si j'ai été la conception d'un tout nouveau système que j'avais hésitez pas à utiliser cette conception en raison de la complexité supplémentaire dans le reste du système - c'est juste pas la peine. Encore moins d'essayer de l'ajouter à une application héritée =)
- 1) Serguei le dit bien, oui, mais... la table de facture n'aurait pas un rapport à la table produits. 2) les Déclencheurs de mise à jour de choses sur insérer faire entraîner (pour mon cas, seulement un peu) plus lent insère, mais la plupart de mes charges de travail sont très à lecture intensive. Vous pourriez lot de ce processus à exécuter pendant la nuit, horaire, hebdomadaire,... que ce soit. Nettoyage de la base de copier, dupliquer roll-up qui rend les choses plus vite. Temps / espace compromis.
InformationsquelleAutor Jeff Ferland
7

Vous soulevez des points valables, cependant, vous ne sont pas totalement claires sur la normalisation et ce qu'il signifie, par exemple dans

1) La demande de conserver les factures qu'ils ont été denormalizes les données sont complètement et totalement faux.
Prenons prix par exemple - si vous avez une exigence de l'entreprise qui indique que vous avez à garder l'historique des prix pour les garder seul prix actuel est mauvais et qu'il brise les exigences. Et il n'a rien à voir avec la normalisation, c'est tout simplement pas conçu ainsi. Dénormalisation de l'est sur l'introduction des possibilités pour de l'ambiguïté dans votre modèle (et autres objets), et dans ce cas vous ne sont tout simplement pas la modélisation de votre espace de problème correctement.

Il n'y a rien de mal dans la modélisation de votre base de données à l'appui des données temporelles (ou le contrôle de version et/ou de séparer les zones de la base de données dans l'archive/temporel et l'ensemble de travail).

À la recherche à la normalisation sans regarder la sémantique (en termes d'exigences) n'est pas possible.

Aussi, si votre développeur senior ne peut pas voir la différence alors je pense qu'il n'a pas son ancienneté dans le SGBDR de développement 😉

2) la Deuxième partie est en effet la dénormalisation. Toutefois, si vous exécutez à travers les hauts DB analyste qui a gravement prêche la normalisation, vous allez l'entendre lui dire qu'il est parfaitement acceptable de dénormaliser aussi longtemps que vous le faites consciemment et de s'assurer que les avantages de l'embonpoint des lacunes et que les anomalies ne va pas vous mordre. Ils vous diront également de normaliser le modèle logique et que, dans le modèle physique vous êtes autorisé à s'écarter de l'idéal à des fins diverses (rendement, l'entretien, etc...). Dans mon livre, le principal objectif de la normalisation est de sorte que vous n'avez pas les anomalies cachées (voir cet article sur le 5NF par exemple)

La mise en cache des résultats intermédiaires est permis, même sur normalisé bases de données et même par les plus grands évangélistes de normalisation - vous pouvez le faire à la couche application (comme une sorte de cache) ou vous pouvez le faire au niveau base de données ou vous pouvez avoir un entrepôt de données à de telles fins. Ce sont tous des choix valables et n'ont rien à voir avec la normalisation de la logique du modèle.

Aussi, comme votre comptable vous devriez être capable de le convaincre que ce qu'il réclame est pas une bonne façon de tester et de développer un ensemble de tests (peut-être avec lui) qui permettra d'automatiser les tests du système sans que les utilisateurs d'intervention et de vous donner plus de confiance que votre système est exempt de bugs.

D'autre part, je sais de systèmes qui obligent les utilisateurs à entrer des informations en double, comme pour entrer le nombre de lignes sur la facture avant ou après la saisie réelle des lignes, pour s'assurer que l'entrée est terminée. Cette donnée est "dupliqué" et vous n'avez pas à stocker si vous avez une procédure qui permettra de valider l'entrée. Si cette procédure vient plus tard, il est permis de stocker le "anormale" data - encore une fois, la sémantique de la justifier et vous pouvez regarder le modèle normalisé. (il est bénéfique pour envelopper votre tête autour de ce concept)

EDIT:
Le terme "anormale" dans (2) n'est pas correct si vous regardez la définition formelle des formes normales, et si vous considérez une conception dénormalisée si il respecte pas l'une des formes normales (pour certaines personnes, c'est évident et il n'y a pas d'autre moyen à ce sujet).

Encore, vous pouvez me faire à l'idée que beaucoup de personnes, et pas nécessaire inutiles des textes à utiliser le terme de normalisation de tout effort qui tente de réduire la redondance dans la base de données (un peu comme un exemple, vous trouverez des articles scientifiques, par qui je ne dis pas qu'ils doivent être à droite, comme un avertissement qu'il est commun, que les appels provenant des attributs d'une forme de dénormalisation, voir ici).

Si vous voulez faire référence à certains plus de cohérence et d'autorités reconnues (encore une fois, n'est pas reconnu par tous), peut-être que les mots de C. J. Date peut faire une distinction claire:

Beaucoup de théorie du design a à voir avec
la réduction de la redondance, de la normalisation
réduit la redondance dans les relvars,
l'orthogonalité de la réduire à travers
relvars.

qouted de Base de données en profondeur: la théorie relationnelle pour les praticiens

et sur la page suivante

tout comme un échec à normaliser tous les
implique la redondance et peut conduire à
certaines anomalies, ce qui peut avoir un
le non respect de l'orthogonalité.

Donc, le terme approprié pour une redondance à travers relvars est d'orthogonalité (en gros toutes les formes normales parler seul relvar donc, si vous regardez strictement à la normalisation qu'il ne serait jamais suggérer d'éventuelles améliorations à cause des dépendances entre les différents relvars).

De toute façon, l'un des autres concepts importants lorsque vous envisagez de conception de base de données est également une différence entre logique et physique de la base de données des modèles. Beaucoup de choses qui sont utiles sur le plan physique, tels que des tables avec des sous-totaux ou les index n'ont pas de place dans le modèle logique - où vous essayez d'établir et étudier les relations entre les concepts que vous essayez d'modèle. Et c'est pourquoi on peut dire qu'ils sont acceptables et qu'ils ne ruine pas le design.

Lignes parfois peut être un peu flou sur ce qui est logique du modèle et ce qui est du modèle physique. En particulier, par exemple un tableau avec des sous-totaux. Pour les considèrent comme faisant partie de la mise en œuvre physique et l'ignorer sur le niveau logique, vous devez:
- s'assurer que les utilisateurs (et la demande) ne peut pas mettre à jour la sous-total tableau directement dans une manière qui n'est pas compatible avec leur prédicat (dans un autre mots ont un bug dans le subtotalling procédure)
- s'assurer que les utilisateurs (et la demande) ne peut pas mettre à jour la table sur laquelle elles sont dépendantes sans mise à jour de la sous-total (en d'autres termes que certaines applications ne seront pas supprimer une ligne de la table de détail sans mise à jour du total)
Si vous violez l'une des règles ci-dessus, vous vous retrouverez avec base de données incohérente qui fournira incompatible faits. (Dans ce cas, si vous voulez officiellement la conception d'une procédure de résolution ou d'examiner les problèmes causés, vous ne voudrais pas le considérer simplement une table supplémentaire, il existerait au niveau logique; là où il ne devrait pas être).

Aussi, la normalisation dépend toujours de la sémantique et les règles de gestion que vous essayez d'modèle. Par exemple DBAPerformance donne un exemple dans lequel le stockage de la TaxAmount dans la table des transactions n'est pas anormale de la conception, mais il omet de mentionner que cela dépend de ce genre de système que vous essayez d'modèle (est-ce évident?); par exemple, si la transaction a un autre attribut appelé TaxRate il sera généralement dénormalisée, car il y a de la dépendance fonctionnelle sur un ensemble d'attributs non-clé (TaxAmount = Quantité * TaxRate => FD: Montant,TaxRate -> TaxAmount), et l'une d'elles doit être supprimé ou être cohérentes.

Évidemment, direz-vous, mais, si le système de construction est une société d'audit, alors vous pourriez ne pas avoir de dépendance fonctionnelle - ils peut-être l'audit de quelqu'un qui est à l'aide de calculs manuels ou a logiciel défectueux ou doit avoir la capacité d'enregistrer des données incomplètes et le calcul pourrait être mal à l'origine, et en tant que société d'audit, vous devez enregistrer le fait qu'il s'est passé.

Ainsi, la sémantique (prédicats) qui sont déterminés par les exigences de l'influence si l'une des formes normales sont brisés en influençant les dépendances fonctionnelles (en d'autres termes correctement établir des dépendances fonctionnelles est assez importante partie de la modélisation lorsque vous vous efforcez de base de données normalisée).
- -1 (2) n'est pas la "dénormalisation". le reste, qui découle de cette notion incorrecte, est également incorrect.
- ok, d'accord, au sens strict, sur la dé-normalisation, et les ont mis dans un montage. Si vous allez répondre, veuillez vous abstenir de généralisations telles que wikipédia est un cloaque, etc et merci de ne citer quelque chose.
- 1) "mais il oublie de mentionner que cela dépend de ce genre de système que vous essayez d'modèle": à l'évidence vous avez des problèmes de lecture; la lecture de ma Réponse, là encore, lentement. 2) Votre compréhension de la dénormalisation dans l'exemple fourni reste carrément incorrect (plus de détails dans ma Réponse).
- re 1) je suis ajout pour votre réponse en mentionnant que la sémantique de l'influence des FDs, qui influent sur la conformité à la NFs. Encore une fois, vous n'avez pas parlé de cela. Votre réclamation que j'ai des problèmes de lecture n'est pas liée à la cité de texte 2) L'exemple fourni montre comment 3FN peuvent être brisés ou être satisfaits en fonction de la sémantique de l'attribut. C'est carrément correct. Voir les détails ci-dessus.
- laissez-moi savoir quand le torrent s'est arrêté. Il n'est pas possible pour vous à "ajouter" à ma réponse. Essayez de vous tenir debout sur votre propre sans faire référence à ma réponse, sans tomber.
- êtes-vous vraiment conscient que l'argumentum ad hominem est erreur de logique? Bien sûr, il est possible d'ajouter des uns et des autres réponses, il est effectivement préférable de répéter les choses et différentiel de points de vue sur un sujet sont utiles. Si je dis "si votre développeur senior ne peut pas voir la différence alors je pense qu'il n'a pas son ancienneté dans le SGBDR développement" et de vous le dire plus tard "Votre confrère principal est un développeur, pas un modeleur de données", puis que vous ajoutez/raffinage quelque chose qui a déjà été dit. Il est possible pour les autres à faire de même et d'être juste (même accidentellement).
InformationsquelleAutor Unreason
4

Je suis d'accord avec votre principal sujet (1). Une opération de ligne de la table doit capturer l'intégralité de l'etat au moment de la transaction. Période. Ce que vous êtes suggérant n'enregistre pas les données réelles, il est donc irrecevable. Je suis également d'accord sur (2). Quelle que soit l'entreprise veut par le moyen de croiser les informations, vous devez mettre en œuvre. La comptabilité est basée sur la vérification, à double entrée, rouler jusqu'livres, etc. Vous devez le faire. C'est si fondamental que vous ne devriez même pas le regarder comme la dénormalisation, tout comme la mise en œuvre de l'exigence de l'entreprise.
- Oui je pense que je suis trop pédant. Merci pour l'aperçu des systèmes de comptabilité EJP.
- double entrée de la tenue des livres n'est pas anormale (ne laissez pas le double de vous induire en erreur - il seulement, pour que chaque transaction que vous avez besoin d'avoir deux comptes, de sorte qu'il est à propos de l'intégrité référentielle des données et de ne pas la dénormalisation des données). Comme pour croiser les informations et de rouler jusqu' - c'est un meilleur exemple. Marque encore le principal problème est qu'il est de ne pas séparer les logiques de conception physique, voir ma réponse.
- Je ne l'ai pas dit est dénormalisée, ne suis-je?
- Vous avez raison, désolé, je l'ai lu dans le mauvais contexte.
InformationsquelleAutor user207421
4

Votre développeur senior rend extrêmement valable points. J'ai appris que ces à la dure par moi-même l'entretien de systèmes qui ne sont pas de normaliser les données historiques.

Dans un sens, c'est pas vraiment l'ajout de frais généraux à la base de données. Vous êtes à la création de la facture des tables à partir des données existantes dans la base de données. Une facture est un instantané dans le temps. De normaliser l'information dont vous avez besoin pour produire cette facture peut rendre votre établissement de rapports de manière beaucoup plus facile. Lorsque vous sont nécessaires pour produire un nouveau rapport et devrait le faire rapidement, vous apprécierez la dénormalisation.

En termes de total dans la base de données. Ce qui a sauvé mon cul avant quand j'ai apporté une modification à une demande qui a provoqué les numéros de ne pas ajouter de la même façon (pas aussi difficile que vous pouvez penser). Sur une application en direct les totaux m'a donné une certaine place dans le but de corriger les écarts. J'ai écrit à ce sujet avant, vous pouvez le lire ici: http://jlrand.com/?p=95

InformationsquelleAutor Jonathan Rand
3

1) Ne nécessite pas de dénormalisation. Vous avez juste besoin de déterminer le niveau de détail de chaque modification que vous avez besoin et persistent avec une clé appropriée.

2) n'A rien à voir avec la dénormalisation. Le stockage des données de synthèse ne fait pas de la base de données dénormalisée. Stocker les résultats provenant d'autres attributs clés dans le même tableau serait un exemple de la dénormalisation, mais qui ne semble pas être ce que vous êtes en train de parler.
- eh bien en fait 2) peut être considérée comme anormale - il peut permettre à tous de modification des anomalies de se produire (en.wikipedia.org/wiki/...).
- David est à droite. Le Wiki est un cloaque, pas la peine de discuter de ce qu'il dit aujourd'hui. Les tableaux de synthèse sont supplémentaire tables pour la vitesse; ils ne font pas partie de la Normalisées db. Il n'y a pas d'anomalie de mise à jour pour les dernières années, total de la facture (il n'y est pour aujourd'hui, et qui ne doit pas être résumé). 5NF est, par définition, indépendamment de ce que wiki dit cette semaine, zéro mise à jour des anomalies. Ils sont encore à essayer de comprendre la "définition de la mise à jour de l'anomalie.
- ce n'est pas à partir de cette semaine, la définition de la modification des anomalies sont de Codd (Poursuite de la Normalisation de la Base de Données Modèle Relationnel. IBM, Rapport de Recherche, San Jose, Californie RJ909: (1971)).
- aussi, si j'ai peut-être un peu osé, je me suis surtout d'accord avec votre argument que ces tableaux supplémentaires ne font pas partie de la normalisées db. Ils font partie de denormalised db. Ce qui était mon point. 😀 (si je veux être totalement précis, je dirais qu'ils sont denormalised si il n'y a pas de garantie au DBA niveau, comme les déclencheurs, que les valeurs dans 2 tables vont être conforme à tous les temps).
- L'un des objectifs de la normalisation est de supprimer des données modification des anomalies, mais cela ne signifie pas un schéma normalisé est entièrement libre. Un 5NF schéma peut encore avoir de la redondance pour la même raison les données dupliquées dans d'autres relations. Il n'est donc pas exact de dire qu'un tableau récapitulatif est automatiquement dénormalisée, redondants ou non.
- Je suppose que ça dépend de l'usage de la parole denormalised - si vous entendez par "briser tout de 1FN-6NF", alors vous avez raison. Si vous l'utilisez pour désigner l'existence de la mise à jour des anomalies alors que je suis en droit (la plupart du temps, il m'arrive de l'utiliser dans l'autre sens aussi 😀 ).
- Au moins, le terme "anormale" implique qu'il y a certains correspondant à la Forme Normale de qui supprime l'anomalie. Si il n'y en a pas, alors quel est le point de l'appeler "anormale"? Presque tous les non-trivial schéma de base de données comprendra la redondance et donc des anomalies de certains description. En fait, je mets quiconque au défi de venir avec vraiment utile en conception de base de données qui a permis à aucune modification de données anomalies à tous. Par votre définition à peu près chaque base de données devrait être "anormale" et, par conséquent, il ne serait pas utile d'utiliser le mot à tous.
- non, comme je l'ai dit avant - E. F. Codd définition à partir de 1970, la dénormalisation se réfère à '1. Gratuit la collection de relations indésirables d'insertion, de mise à jour et de suppression des dépendances; 2... " (voir le lien précédent). Cette définition, a fait a fait plus de 40 ans, AVANT certains des plus formes normales ont été définis (comme un plan pour eux). Par conséquent, il est permis d'utiliser le terme dans ce sens. Comme pour chaque base de données de la rupture de celui - ci, non, en fonction de la sémantique de votre modèle, vous pouvez en effet avoir une base de données (en particulier du modèle logique) avec pas pas souhaitable de mettre à jour les dépendances.
- Vous êtes en citant hors contexte. Ceux-ci sont Codd les remarques à propos de la Normalisation, mais ils ne sont pas une définition de la Dénormalisation. Je serais intéressé de voir des exemples de non-trivial de la base de données avec pas de mise à jour des anomalies. J'ose dire que c'est à peu près possible, mais autant que je sais que c'est impossible à prouver, car il n'existe pas de manière formelle à identifier la redondance. Date/McGoveran est venu avec un exemple classique. Une paire de relations appelle l'Aime et le Déteste. Ils sont "normalisés" (6NF), mais aussi le potentiel de modification des données anomalies parce qu'ils sont mutuellement exclusifs.
- Vous ou un wiki sont misquoting ou couchée. Sur quelle page de la Codd livre est-il dire que les tableaux de synthèse sont "denormalised' ? Arrêter de parler non-sens, de la taille de votre langue, et s'en tenir à des points techniques précis, s'il vous plaît, est-ce DONC, pas votre blogsite. Personne n'est intéressé par votre avis de "denormalised". Si vous avez de lui même (non résumé) de la valeur dans deux endroits, vous avez une brute Normalisation d'erreur, il est Unnormalised. Si vous avez eu une valeur après Normalisation, puis introduit la valeur de retour dans la db, il est Denormalised, et maintenant vous avez une mise à Jour de l'Anomalie.
- vous avez raison, ce n'est pas un forum ou de mon blog personnel, désolé pour le bruit. Ouvrira une question.
- href="http://stackoverflow.com/questions/4312092/denormalization-of-two-relations" title="dénormalisation de deux relations">stackoverflow.com/questions/4312092/...
- Et alors ? Vous manquez le point qu'un tableau de Synthèse n'est pas un "denormalistion". Lire ma Réponse pour plus de détails.
- vous êtes un peu lent aujourd'hui - j'ai déjà admis que, en vertu de la définition stricte, le Résumé de la table n'est pas "dé-normalisation/ed" et que, selon C. J. Date le terme approprié ici est "orthogonalité" - qui, ainsi, conduit à la possibilité de mise à jour de certaines anomalies (cette similitude de l'effet et le fait que les deux concepts découlent de codd la pensée de l'/remarques à propos de dénormalisation sont probablement la raison pour laquelle les gens ont tendance à utiliser le terme dans un sens plus général).
InformationsquelleAutor nvogel
1

Pour #1

La facture doit être calculée à partir de la vente et les paiements. Si vous n'avez pas détaillé des données de vente, y compris les prix/produit/remise/frais de port/etc commencer par là.

Pour #2

L'écriture d'un système de comptabilité dans la base à partir de zéro est un gros projet. Assurez-vous que vous avez les comptables vous donnent les règles d'affaires de sorte que vous pouvez mesurer vos systèmes de précision. La dernière chose que vous voulez est la CAF étape dans le DBA de réunion et d'annoncer la DB est la surcharge de la clientèle, même pire, vous vous êtes undercharging et la conduite de la société.

Si vous avez SQL Server donner l'Aventure Œuvres db un coup d'oeil. Si vous détestez MS puis regarder l'Aventure de Travaux et de ne pas le faire de cette façon.
- Quelle belle suggestion à propos de la vérification de la base de données AdventureWorks!! L'installation de maintenant...
InformationsquelleAutor RC_Cleland
0

Normalisation de base de données supprime les doublons et fait des requêtes sql de mise à jour des données plus efficace (et donne quelques autres améliorations).

Mais si la plupart de vos requêtes sont utilisés pour les données de la sélection et de sélectionner les requêtes de se connecter à plusieurs tables à la fois, vous pouvez envisager de dénormalisation de ces tables. Il permettra d'augmenter la quantité d'espace disque nécessaire pour les données, le temps d'exécution de sql requêtes de mise à jour, mais permettra d'améliorer les requêtes select.
- Oui, je comprends que la normalisation contribue à maintenir l'intégrité des données pour une base de données transactionnelle (insertions, mises à jour, suppressions), mais n'est pas approprié pour un entrepôt de données est uniquement soumis à la sélectionne.
- "[Dénormalisation] va augmenter ... le temps d'exécution de sql requêtes de mise à jour" - en général, ce n'est pas vrai. Si la table est souvent modifié (c'est à dire les verrous exclusifs sont émis) ce sera de mise à jour lente/requêtes de type insert sur la table de référence depuis ces requêtes exigera également lire les verrous sur la table étrangère (vérification des contraintes).
- la dénormalisation pouvez vous référer au regroupement et à l'ajout de données redondantes. Les données redondantes sont pour accélérer sélectionne (tels que des sous-totaux, etc) et doit être maintenu. Dans de tels cas, en effet, elle ralentit toutes les mises à jour (insert, mises à jour, suppressions). Ce que vous appelez pour, probablement, est simple dénormalisation que les groupes de tables (en particulier celui de l'un des tableaux) - dans ce cas, sur les systèmes modernes, vous pouvez avoir une meilleure performance globale pour les choisir et les mises à jour, au risque de salir la conception et paralysant votre capacité à faire des vérifications d'intégrité. Ce qui est un pas de problème si vous pouvez garantir l'intégrité des données.
- C'est un non-sens. J'ai déjà posté les détails.
InformationsquelleAutor Alexandr
0

Il me semble que si vous envisagez plutôt ou pas, vous devez créer un entrepôt de données. Vous ne devriez jamais éliminer votre base de données à des fins historiques des fins de reporting. Création d'une archive et le stockage de vos informations dans votre entrepôt de données permettra de faire les deux: pour éliminer la plupart de l'information et de conserver les données de l'histoire.

InformationsquelleAutor Lesly Revenge

Vous devez vous connecter pour publier un commentaire.