Inhalt anzeigen: Englisch mit deutscher Übersetzung Englisch mit deutscher Übersetzungnur Englischnur deutsche Übersetzung Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden. Editor's Note Editor's Note Howard Dierking I recently had the opportunity to author the editor's note for TechNet Magazine. I have to say that, being a developer, addressing an audience of IT professionals was a bit daunting. Both disciplines are vital to any business, but many times their paths only cross when something is broken. However, I believe that when it comes to the management of data, both developers and IT professionals need to be involved up front in planning solutions. Given that the theme of that particular TechNet Magazine issue was business intelligence and that the theme of this issue of MSDN Magazine is data, I'll address some of the main points I made in that editor's note but more from the developer perspective. When you get right down to it, the role that software generally plays in most businesses is to get, process, and store data. Therefore, while we may have all sorts of high-level discussions and debates around architectural patterns and object-oriented heuristics, the fact remains that the most elegantly designed application is still effectively taking data from somewhere, doing something to it and putting it somewhere else. Now don't get me wrong—I'm not suggesting that design heuristics we argue so fervently over are immaterial. After all, a Ford Model T and a Lamborghini Diablo both accomplish the task of moving people from one place to another; but given a choice between the two, it's pretty clear in my mind which one I would choose. Instead, I'm suggesting that we put the same level of thinking and technology consideration into data structure and management that we do for our class models. Furthermore, I'm not just talking about relational schema design or whether or not to use stored procedures. I'm talking much more generally about understanding how the business needs to consume data in a way that provides meaningful value. One prime example of poor application planning and design as it relates to data is found in reporting. Forget the object-relational impedance mismatch for a moment—the transactional-reporting impedance mismatch seems to be one of those problems that rears its head in just about every business support system that we touch. And in nearly every case, the transactional concerns win by a landslide. Reporting requirements become limited by the inherent complexity and performance limitations found in the highly normalized database schemas of well-designed transactional systems. Even when well-meaning system designers try to accommodate both sets of concerns in the application schema, the result generally does slightly better at meeting the reporting requirements, and it does so at the great expense of the transactional requirements. So what's the solution? First, get comfortable with the reality that there is not, nor will there ever be, a relational database design that will successfully meet both transactional and reporting requirements—at least not in a sustained way. From there, start assuming that your system should have at least two database schemas—one highly normalized schema that is optimized for processing transactions and one denormalized schema that is optimized for reporting and for mining. What I'm describing is known as the difference between relational and dimensional data modeling. For a great resource on getting started with dimensional modeling, check out The Data Warehouse Toolkit by Ralph Kimball and Margy Ross (Wiley, 2002). Freeing yourself from the burden of trying to build a single relational schema that takes into account both reporting and transactional concerns will enable you to truly optimize both new schemas according to how they are actually used. Put another way, you will have effectively shifted your problem from a design problem to an extract, transform and load (ETL) problem—and the latter is generally a much more straightforward type of problem to solve. Additionally, I think that once you dig into some of the technologies that support dimensional modeling, from online analytical processing to data mining, you may just find that implementing reporting requirements can actually become a great deal more fun. At the very least, think of it as ensuring that your databases follow the single responsibility principle. Visit us at msdn.microsoft.com/magazine. Questions, comments, or suggestions for MSDN Magazine? Send them to the editor: mmeditor@microsoft.com. Thanks to the following Microsoft technical experts for their help with this issue: Mike Barnett, Bob Brumfield, Pablo Castro, Jeff Currier, Diego Dagum, Nelly Delgado, Jeff Derstadt, Manuel Fahndrich, Shawn Farkas, Elisa Flasko, Shawn Hernan, Tim Heuer, Carl Perry, Ayende Rahien, and Blaine Wastell. Anmerkung des Redakteurs Anmerkung des Redakteurs Howard Dierking Ich hatte kürzlich die Möglichkeit Redaktionshinweis für TechNet Magazin Autor. Ich habe, wird ein Entwickler, eine Zielgruppe von IT-Experten Adressierung etwas schwierige waren. Beide Disziplinen sind wichtig für Unternehmen, aber oft deren Pfade nur Kreuz, wenn etwas nicht eingehalten wird. Allerdings glauben ich, wenn es um die Verwaltung der Daten geht, Entwickler und IT-Experten beteiligt vorab Planung von Lösungen sein müssen. Tatsache, dass das Design, bestimmten Problem TechNet Magazin Business Intelligence wurde und dass das Design des Problems MSDN Magazin Daten, werde ich einige der wichtigsten Punkte, Adresse ich in die Redaktionshinweis jedoch mehr aus Sicht des Entwicklers vorgenommen. Wenn Sie rechts unten nach es erhalten, ist die Funktion Software in der Regel in den meisten Unternehmen abrufen, Prozess, und Speichern von Daten. Obwohl wir alle Arten von allgemeinen Diskussionen und Diskussionen um Architekturmuster und objektorientierte Heuristik haben kann, bleibt die Tatsache, dass die meisten Eleganter entworfene Anwendung noch effektiv Notizen Daten aus irgendwo, etwas zu es ausführen, und es woanders ist. Jetzt nicht abrufen mir falsch – ich bin nicht vorschlagen, dass wir also fervently über argumentieren Entwurf Heuristik irrelevant sind. Nachdem alle ein Ford Modell T und erreichen Lamborghini Diablo beide die Aufgabe des verschieben Personen von einem Ort zu einem anderen;eine Auswahl zwischen den beiden angegeben, es ist jedoch ziemlich klar in meine Gedanken, die ich entscheiden würden. Stattdessen verwende ich vorschlagen, legen wir dieselben denken und Technologie berücksichtigt in die Datenstruktur und Verwaltung, die wir für unsere Klasse Modelle. Darüber hinaus habe nicht nur relationales Schemaentwurf oder ob gespeicherte Prozeduren verwenden Rede. Ich bin viel im Allgemeinen sprechen verstehen, wie die Geschäftsanforderungen, Daten in einer Weise zu verwenden, die sinnvollen Wert bereitstellt. Wurde ein gutes Beispiel für unzureichende Anwendung Planung und Entwurf im Zusammenhang mit Daten in Berichten gefunden. Vergessen Sie das objektrelationale Impedance Mismatch für einen Moment – das Transaktions-reporting Impedance Mismatch scheint eines dieser Probleme, die rears den Kopf in fast allen Geschäftssystem Unterstützung, die wir berühren. Und in fast jedem Fall die transaktionale Aspekte gewinnen durch eine Landslide. Berichterstellung Anforderungen werden durch die inhärenten Komplexität und Leistung Einschränkungen, die in der stark normalisierte Datenbankschemas gut entworfene Transaktionssysteme gefunden beschränkt. Auch wenn wohlmeinende System Designer versuchen, im Allgemeinen beide Probleme in der Anwendung Schema das Ergebnis aufzunehmen etwas geschieht besser zur Besprechung Anforderungen an die Berichterstellung, und es an die großartige Ausgaben für die Transaktionsreplikation Anforderungen. Was ist die Lösung? Zunächst erhalten Sie Erfahrung mit der Realität, die nicht vorhanden ist, noch es jemals werden, eine relational Database Design, die erfolgreich Transaktions- und Berichterstellung Anforderungen erfüllen wird – zumindest nicht in einer anhaltend Weise. Von dort starten, vorausgesetzt, dass Ihr System mindestens zwei Datenbankschemas haben sollen – ein stark normalisiertes Schema, das zum Verarbeiten von Transaktionen und ein denormalisierte Schema, das für die Berichterstellung und Mining optimiert ist, optimiert ist. Was ich beschrieben habe wird als die Differenz zwischen relationalen und dimensionale Datenmodellierung bezeichnet. Checken Sie für eine hervorragende Ressource auf Erste Schritte mit Dimensionsmodellierung aus die Data Warehouse Toolkit von Ralph Kimball und Margy Ross (Wiley, 2002). Selbst von der Last freigeben, um ein einzelnes relationales Schema zu erstellen, die berücksichtigt beide Berichte und transaktionale Bedenken ermöglichen wirklich optimieren beiden neuen Schemas nach wie Sie tatsächlich verwendet werden. Anders ausgedrückt, Sie werden haben effektiv verschoben Ihr Problem eines Designproblems um einen Auszug, zu transformieren und laden (ETL) Problem – und die zweite ist im Allgemeinen eine viel einfacher Art von Problem zu lösen. Darüber hinaus denke ich, sobald Sie in einige der Technologien, die Dimensionsmodellierung unterstützen untersuchen, aus online analytische Verarbeitung, Datamining Sie nur finden möglicherweise darin, dass Anforderungen an Berichterstellung implementieren tatsächlich viel mehr Spaß werden kann. Zumindest betrachten Sie als sicherstellen, dass Ihre Datenbanken das Prinzip der einzigen Verantwortung folgen. Besuchen Sie uns unter msdn.microsoft.com/magazine. Fragen, Kommentare oder Vorschläge für MSDN Magazin? Senden Sie an der Editor: mmeditor@microsoft.com. Dank der folgenden technischen Experten von Microsoft für Ihre Hilfe bei diesem Problem: Mike Barnett, Bob Brumfield, Pablo Castro, Jeff Currier, Diego Dagum, Nelly Delgado, Jeff Derstadt, Manuel Fahndrich, Shawn Farkas, Elisa Flasko, Shawn Hernan, Tim Heuer, Carl Perry, Ayende Rahien und Blaine Wastell.

Current Issue     Browse All MSDN Magazines   Tip: Click the printer button in your browser toolbar to get the printer friendly version of this article.