Beziehungen zwischen Objektmengen und ihren Typen. Einfache und komplexe Objekte. Arten von Beziehungen zwischen Domänenobjekten

1. Grundlegende Konzepte und Begriffe zum Thema
„INFORMATIONSMODELL IST DIE GRUNDLAGE FÜR DEN BAU
DATENBANKMANAGEMENTSYSTEM.

Jede Zivilisation muss sich mit der Informationsverarbeitung auseinandersetzen. Mit der Entwicklung der Wirtschaft und dem Bevölkerungswachstum steigt auch die Menge der vernetzten Daten, die zur Lösung wirtschaftlicher und administrativer Probleme erforderlich sind.

@ Das Modell zum Sammeln, Speichern, Verarbeiten und Nutzen zusammenhängender Daten, um Informationsflüsse optimal zu verwalten und Probleme in einem bestimmten Themenbereich zu lösen, wird als Informationssystem bezeichnet . Ein solches System soll in erster Linie die menschliche Arbeit erleichtern, muss dazu aber bestmöglich einem sehr komplexen Modell der realen Welt entsprechen.

@ Kern Informationssystem sind die darin gespeicherten Daten . In jedem Unternehmen überschneiden sich Daten aus verschiedenen Abteilungen in der Regel, das heißt, sie werden abteilungsübergreifend genutzt oder allgemein gemeinsam genutzt. Beispielsweise sind für Managementzwecke häufig unternehmensweite Informationen erforderlich. Ohne Informationen über Lagerbestände ist eine Bestellung von Bauteilen nicht möglich. Die im Informationssystem gespeicherten Daten müssen in der Form, in der sie für die spezifischen Produktionsaktivitäten des Unternehmens benötigt werden, leicht zugänglich sein. In diesem Fall spielt die Art der Datenspeicherung keine wesentliche Rolle. Heutzutage finden wir in Unternehmen ein traditionelles Datenverarbeitungssystem, bei dem ein Mitarbeiter Daten manuell in einem Ordner ablegt und daneben - modernes System mit den schnellsten Computern, hochentwickelter Ausrüstung und Software. Trotz ihrer auffälligen Unterschiede müssen beide Systeme zu einem bestimmten Zeitpunkt, an einer bestimmten Person, an einem bestimmten Ort und zu begrenzten Kosten zuverlässige Informationen bereitstellen.

Um den Prozess des Aufbaus eines Informationssystems zu verstehen, müssen Sie eine Reihe von Begriffen kennen, die zur Beschreibung und Darstellung von Daten verwendet werden.

@ Fachbereich ist der Teil des realen Systems, der für diese Studie von Interesse ist.

Beim Entwurf automatisierter Informationssysteme wird das Themengebiet durch Datenmodelle mehrerer Ebenen repräsentiert. Die Anzahl der verwendeten Schichten hängt von der Komplexität des Systems ab, umfasst aber in jedem Fall logische und physikalische Schichten. Der Themenbereich kann sich auf jede Art von Organisation beziehen (z. B. eine Bank, eine Universität, ein Krankenhaus oder eine Fabrik).

Es ist zu unterscheiden zwischen dem gesamten Fachgebiet (großes produzierendes Unternehmen, Lager, Kaufhaus etc.) und der Organisationseinheit dieses Fachgebiets. Eine Organisationseinheit wiederum kann ihr Fachgebiet repräsentieren (z. B. eine Karosseriewerkstatt eines Automobilwerks oder eine Datenverarbeitungsabteilung eines Computerherstellers). Dabei können Werkstätten und Abteilungen selbst bestimmten Fachgebieten entsprechen.

Die zur Beschreibung des Themenbereichs erforderlichen Informationen hängen vom tatsächlichen Modell ab und können Informationen über Personal, Löhne, Waren, Rechnungen, Rechnungen, Verkaufsberichte, Labortests, Finanztransaktionen, Krankenakten, also Informationen über Personen, Orte, Gegenstände, umfassen , Veranstaltungen und Konzepte.

@ Objekt ist ein Element des Informationssystems, über das wir Informationen speichern. In der relationalen Datenbanktheorie wird ein Objekt als Entität bezeichnet.

Das Objekt kann sein real(zum Beispiel eine Person, ein Objekt oder ein Ort) und abstrakt(z. B. eine Veranstaltung, ein Kundenkonto oder ein Kurs, an dem Studierende teilnehmen). Im Bereich des Autoverkaufs sind Beispiele für Objekte AUTOMODELL, KUNDE und KONTO. In einem Warenlager ist dies ein LIEFERANT, eine WARE, eine SENDUNG usw. Jedes Objekt verfügt über bestimmte Eigenschaften, die im Informationssystem gespeichert sind. Bei der Verarbeitung von Daten muss man sich häufig mit einer Ansammlung homogener Objekte, wie z. B. Mitarbeitern, auseinandersetzen und für jedes von ihnen Informationen über die gleichen Eigenschaften erfassen.

@ Objektklasse bezeichnet eine Sammlung von Objekten, die denselben Satz an Eigenschaften haben.

Somit ist für Objekte derselben Klasse der Satz an Eigenschaften derselbe, obwohl die Werte dieser Eigenschaften für jedes Objekt natürlich unterschiedlich sein können. Beispielsweise können die MODEL-Eigenschaften der Objektklasse für jedes Objekt natürlich unterschiedlich sein. Beispielsweise verfügt die Objektklasse CAR MODEL über denselben Satz von Eigenschaften, die die Eigenschaften von Autos beschreiben, und jedes Modell verfügt über unterschiedliche Werte für diese Eigenschaften.

Objekte und ihre Eigenschaften sind Konzepte der realen Welt. In der Informationswelt, die im Kopf eines Programmierers existiert, sprechen sie über die Eigenschaften von Objekten.

@ Attribut- Dies ist eine Informationsanzeige der Eigenschaften eines Objekts. Jedes Objekt zeichnet sich durch eine Reihe grundlegender Attribute aus.

Ein Automodell wird beispielsweise durch Karosserietyp, Hubraum, Zylinderzahl, Leistung, Abmessungen, Name usw. charakterisiert. Ein Kunde eines Ladens, der Autos verkauft, verfügt über Attribute wie Nachname, Vorname, Vatersname, Adresse und möglicherweise eine Identifikationsnummer. Jedes Attribut im Modell muss einen eindeutigen Namen haben – einen Bezeichner. Attribut bei Implementierung Informationsmodell auf einem beliebigen Speichermedium wird oft aufgerufen Datenelement, Datenfeld oder nur ein Feld.

Reis. 1.1. Drei Bereiche der Datenpräsentation.

@ Tisch- Dies ist eine regelmäßige Struktur, die aus einer endlichen Menge von Datensätzen desselben Typs besteht. In einigen Quellen wird die Tabelle als Relation bezeichnet.

Wir werden versuchen, den letzten Begriff zu vermeiden, da mit der Entwicklung der relationalen Theorie „Beziehung“ zusammen mit dem Begriff „Verbindung“ häufig als Verbindungen zwischen Tabellen bezeichnet wurde. Jeder Datensatz einer Tabelle besteht aus einer endlichen (und identischen!) Anzahl von Feldern und ein bestimmtes Feld jedes Datensatzes einer Tabelle kann nur einen Datentyp enthalten.

@ Datenwerte stellen die tatsächlichen Daten dar, die in jedem Datenelement enthalten sind.

Das Datenelement „MODEL NAME“ kann Werte wie „Voyager“96 3.8 Grand“, „Continental 4.6“ oder „Crown Victoria 4.6“ annehmen. Je nachdem, wie die Datenelemente das Objekt beschreiben, können ihre Werte quantitativ sein , qualitativ oder beschreibend. Informationen zu einem bestimmten Themengebiet können durch mehrere Objekte dargestellt werden, die jeweils durch mehrere Datenelemente beschrieben werden. Die von Datenelementen akzeptierten Werte werden aufgerufen Daten.

@ Ein einzelner Satz von Werten, die von Datenelementen akzeptiert werden, wird aufgerufen Objektinstanz. Objekte sind auf eine bestimmte Weise miteinander verbunden.

@ Das entsprechende Modell von Objekten mit ihren konstituierenden Datenelementen und Beziehungen wird aufgerufen Konzeptmodell Fachbereich. Ein konzeptionelles Modell bietet Einblick in den Datenfluss in einer Domäne.

Einige Datenelemente verfügen über eine Eigenschaft, die für den Aufbau eines Informationsmodells wichtig ist. Wenn wir den Wert kennen, den das Datenelement eines solchen Objekts annimmt, können wir die Werte identifizieren, die andere Datenelemente desselben Objekts annehmen. Wenn wir beispielsweise die eindeutige Modellnummer eines Autos kennen (7), können wir feststellen, dass es sich um einen „Voyager“ 96“ handelt und dass der Hubraum dieses Modells „3778“ beträgt.

@ Schlüsselelement Daten sind ein Element, aus dem die Werte anderer Datenelemente bestimmt werden können.

Zwei oder mehr Datenelemente können ein Objekt eindeutig identifizieren. In diesem Fall werden sie als „Kandidaten“-Schlüsseldatenelemente bezeichnet. Die Frage ist , Welcher Kandidat für den Zugriff auf das Objekt verwendet wird, wird vom Benutzer oder Systemdesigner entschieden. Wichtige Datenelemente müssen sorgfältig ausgewählt werden, da richtige Wahl trägt zur Schaffung des Rechts bei Konzeptmodell Daten.

@ Primärschlüssel ist ein Attribut (oder eine Gruppe von Attributen), das jede Zeile in einer Tabelle eindeutig identifiziert.

Das Konzept eines Primärschlüssels ist äußerst wichtig im Zusammenhang mit dem Konzept der Datenbankintegrität, auf das wir am Ende dieses Abschnitts ausführlich eingehen werden.

@ Alternativer Schlüssel ist ein Attribut (oder eine Gruppe von Attributen), das nicht mit dem Primärschlüssel übereinstimmt und eine Instanz eines Objekts eindeutig identifiziert.

Beispielsweise kann für das Objekt „EMPLOYEE“, das über die Attribute „EMPLOYEE ID“, „NACHNAME“, „NAME“ und „PATRONICAL“ verfügt, die Attributgruppe „NACHNAME“, „NAME“, „PATERNAME“ eine Alternative sein Schlüssel zum Attribut „EMPLOYEE ID“ (vorausgesetzt, dass im Unternehmen keine Mitarbeiter mit vollem Namen arbeiten).

@ Externer Schlüssel ist ein Tabellenattribut, das der Primärschlüssel einer anderen Tabelle ist.

Beispielsweise kann das Attribut MODEL NUMBER eines CAR-Objekts ein Fremdschlüssel für das MODEL-Objekt sein.

@ Datenaufzeichnung ist eine Sammlung von Werten verwandter Datenelemente.

In Abb. 1.2. Diese Datenelemente sind der eindeutige Schlüssel- und Modellname, der Hubraum, die Anzahl der Zylinder und die Motorleistung. Einer der Einträge lautet beispielsweise „7 Voyager’96 3,8 Grand 3778 6.164,0“ . Diese Zeichenfolge stellt die Werte dar, die die Datenelemente des VEHICLE MODEL-Objekts annehmen. Aufzeichnungen werden auf einem Medium gespeichert, das das menschliche Gehirn, ein Blatt Papier, ein Computerspeicher, ein externes Speichergerät usw. sein kann.

MODELL

EINZIGARTIGER MODELLSCHLÜSSEL

Modellname

Arbeitsvolumen (Kubikzentimeter)

Leistung (PS)

GMC Jimmy 4.3

7

Voyager'96 3,8 Grand

3778

164,0

Stealth 3.0

348 Spider 3.4

Abb.1.2. MODEL-Objektdatensätze.

Jeder Datensatz einer Tabelle besteht aus einer endlichen (und identischen!) Anzahl von Feldern und ein bestimmtes Feld jedes Datensatzes einer Tabelle kann nur einen Datentyp enthalten

@ Datentyp charakterisiert die Art der gespeicherten Daten.

Das Konzept eines Datentyps in einem Informationsmodell entspricht völlig dem Konzept eines Datentyps in Programmiersprachen. Typischerweise ermöglichen moderne DBMS die Speicherung von Zeichen, numerischen Daten, Bitfolgen, speziellen numerischen Daten (z. B. Beträge in Geldeinheiten) sowie Daten in einem speziellen Format (Datum, Uhrzeit, Zeitintervall usw.). In jedem Fall sollten Sie bei der Auswahl eines Datentyps die Fähigkeiten des DBMS berücksichtigen, mit dem das physische Modell des Informationssystems implementiert wird.

@ Verbindung ist eine funktionale Beziehung zwischen Entitäten.

Wenn zwischen einigen Entitäten eine Beziehung besteht, beziehen sich Fakten einer Entität auf Fakten einer anderen Entität oder stehen in irgendeiner Weise mit ihnen in Zusammenhang. Die Aufrechterhaltung der Konsistenz funktionaler Abhängigkeiten zwischen Entitäten wird als referenzielle Integrität bezeichnet. Da Beziehungen „innerhalb“ des relationalen Modells enthalten sind, kann die Implementierung der referenziellen Integrität entweder durch die Anwendung oder durch das DBMS selbst (unter Verwendung deklarativer referenzieller Integritätsmechanismen und Trigger) durchgeführt werden.

Beziehungen können durch fünf Hauptmerkmale dargestellt werden:

Art der Verbindung (identifizierend, nicht identifizierend)

Mutterunternehmen;

Untergeordnete (abhängige) Entität;

Kommunikationsstärke (Herzlichkeit);

Akzeptanz leerer (Null-)Werte.

Den Zusammenhang nennt man Identifizieren, wenn die Instanz der untergeordneten Entität durch ihre Beziehung zur übergeordneten Entität identifiziert (eindeutig bestimmt) wird. Die Attribute, die den Primärschlüssel der übergeordneten Entität bilden, sind auch im Primärschlüssel der untergeordneten Entität enthalten. Untergeordnete Entität in einer identifizierenden Beziehung ist immer abhängig.

Die Beziehung wird als nichtidentifizierend bezeichnet, wenn die Instanz der untergeordneten Entität nicht durch eine Beziehung zur übergeordneten Entität identifiziert wird. Die Attribute, die den Primärschlüssel der übergeordneten Entität bilden, sind auch in den Nichtschlüsselattributen der untergeordneten Entität enthalten.

Kommunikationskraft stellt das Verhältnis der Anzahl der Instanzen einer übergeordneten Entität zur entsprechenden Anzahl der Instanzen einer untergeordneten Entität dar. Für jede andere als eine unspezifische Beziehung wird diese Beziehung als geschrieben 1:n.

@ Gespeicherte Prozeduren ist eine Anwendung (Programm), die Abfragen und Verfahrenslogik (Zuweisungsoperatoren, logische Verzweigungsanweisungen usw.) kombiniert und in einer Datenbank gespeichert ist.

Mit gespeicherten Prozeduren können Sie recht komplexe Programme zusammen mit der Datenbank enthalten, die einen großen Arbeitsaufwand erledigen, ohne Daten über das Netzwerk zu übertragen und mit dem Client zu interagieren. Typischerweise beinhalten in gespeicherten Prozeduren geschriebene Programme eine Datenverarbeitung. Somit kann die Datenbank eine funktional unabhängige Anwendungsschicht sein, die mit anderen Schichten interagieren kann, um Abfragen zu empfangen oder Daten zu aktualisieren.

@ Regeln ermöglichen es Ihnen, beim Ändern oder Hinzufügen von Daten zu einer Datenbank (DB) bestimmte Aktionen auszulösen und so die Richtigkeit der darin abgelegten Daten zu kontrollieren.

Normalerweise ist eine Aktion ein Aufruf einer bestimmten Prozedur oder Funktion. Regeln können einem Feld oder Datensatz zugeordnet werden und werden dementsprechend ausgelöst, wenn sich Daten in einem bestimmten Feld oder Tabellendatensatz ändern. Beim Löschen von Daten können Sie keine Regeln verwenden. Im Gegensatz zu Beschränkungen, die nur ein Mittel zur Kontrolle sind einfache Bedingungen Korrektheit der Dateneingabe, Regeln ermöglichen es Ihnen, beliebig komplexe Beziehungen zwischen Datenelementen in der Datenbank zu überprüfen und aufrechtzuerhalten.

@ Referenzielle Integrität stellt sicher, dass der Fremdschlüsselwert einer untergeordneten Entitätsinstanz mit den Primärschlüsselwerten in der übergeordneten Entität übereinstimmt.

Die referenzielle Integrität kann für alle Vorgänge überprüft werden, die Daten ändern.

@ Normalisierung der Beziehungen ist der Prozess des Aufbaus einer optimalen Struktur von Tabellen und Beziehungen in einer relationalen Datenbank.

Der Normalisierungsprozess gruppiert Datenelemente in Tabellen, die Objekte und ihre Beziehungen darstellen. Die Normalisierungstheorie basiert auf der Idee, dass ein bestimmter Tabellensatz bessere Eigenschaften zum Einschließen, Ändern und Löschen von Daten aufweist als alle anderen Tabellensätze, die dieselben Daten darstellen können. Die Einführung der Normalisierung von Beziehungen bei der Entwicklung eines Informationsmodells gewährleistet das minimale Volumen einer physischen Datenbank, das heißt auf jedem Medium aufgezeichnet, und ihre maximale Leistung, was sich direkt auf die Funktionsqualität des Informationssystems auswirkt. Die Normalisierung des Informationsmodells erfolgt in mehreren Stufen (1., 2. und 3. Normalform).

@ Datenwörterbuch ist ein zentralisiertes Repository mit Informationen über Objekte, ihre konstituierenden Datenelemente, Beziehungen zwischen Objekten, ihre Quellen, Bedeutungen, Verwendungen und Präsentationsformate.

@ Integrität gewährleisten Datenbank ist ein System von Maßnahmen, die darauf abzielen, die Richtigkeit der Daten in der Datenbank jederzeit aufrechtzuerhalten.

Die Kosten für die Überprüfung und Aufrechterhaltung der Datenintegrität können einen erheblichen Teil der Gesamtkosten ausmachen betriebsbereit Kosten. Beispielsweise wird in Transportunternehmen zur Kontrolle der Richtigkeit der Dateneingabe aus Reisedokumenten die parallele Eingabe derselben Daten durch mehrere Betreiber praktiziert. Es wird davon ausgegangen, dass die Wahrscheinlichkeit, in diesem Fall denselben Fehler zu machen, äußerst gering ist und ein einfacher Vergleich der Ergebnisse der Eingabe verschiedener Operatoren dabei hilft, fehlerfreie Daten zu erhalten. In einem DBMS wird die Datenintegrität durch eine Reihe spezieller Klauseln sichergestellt, die als Integritätsbeschränkungen bezeichnet werden.

@ Integritätsbedingungen ist eine Reihe spezifischer Regeln, die die Zulässigkeit von Daten und Beziehungen zwischen ihnen festlegen.

Ein automatisiertes Datenverarbeitungssystem basiert auf der Verwendung eines bestimmten Datenmodells oder Informationsmodells. Das Datenmodell spiegelt die Beziehungen zwischen Objekten wider.

2. Reihenfolge der Erstellung eines Informationsmodells

Der Prozess der Erstellung eines Informationsmodells beginnt mit der Identifizierung der konzeptionellen Anforderungen einer Reihe von Benutzern (Abbildung 2.1). Auch für einige Aufgaben (Anwendungen), deren Umsetzung in naher Zukunft nicht geplant ist, können konzeptionelle Anforderungen ermittelt werden. Dies kann die Komplexität der Arbeit leicht erhöhen, trägt jedoch dazu bei, alle Nuancen der für das zu entwickelnde System erforderlichen Funktionalität möglichst vollständig zu berücksichtigen, und verringert die Wahrscheinlichkeit einer Überarbeitung in der Zukunft. Individuelle Benutzeranforderungen werden in einer einzigen „Zusammenfassungsansicht“ integriert. Letzteres wird als konzeptionelles Modell bezeichnet.

@ Konzeptionelles Modell stellt Objekte und ihre Beziehungen dar, ohne anzugeben, wie sie physisch gespeichert werden.

Somit ist ein konzeptionelles Modell im Wesentlichen ein Domänenmodell. Beim Entwerfen eines konzeptionellen Modells sollten alle Bemühungen des Entwicklers hauptsächlich auf die Strukturierung der Daten und die Identifizierung der Beziehungen zwischen ihnen abzielen, ohne Implementierungsmerkmale und Fragen der Verarbeitungseffizienz zu berücksichtigen. Der Entwurf eines konzeptionellen Modells basiert auf einer Analyse der in diesem Unternehmen zu lösenden Datenverarbeitungsaufgaben. Das konzeptionelle Modell umfasst Beschreibungen von Objekten und deren Beziehungen, die im betrachteten Themenbereich von Interesse sind und als Ergebnis der Datenanalyse identifiziert wurden. Dabei handelt es sich um Daten, die sowohl in bereits entwickelten Anwendungsprogrammen als auch in solchen, die erst implementiert werden, verwendet werden.

Das konzeptionelle Modell wird dann in ein Datenmodell übersetzt, das mit dem ausgewählten DBMS kompatibel ist. Es ist möglich, dass sich die im konzeptionellen Modell widergespiegelten Beziehungen zwischen Objekten später als für das gewählte DBMS nicht realisierbar erweisen. Dies erfordert eine Änderung des konzeptionellen Modells. Die Version eines konzeptionellen Modells, die von einem bestimmten DBMS bereitgestellt werden kann, wird als logisches Modell bezeichnet.

@ Logikmodell spiegelt logische Verbindungen zwischen Datenelementen wider, unabhängig von ihrem Inhalt und ihrer Speicherumgebung.

Das logische Datenmodell kann relational, hierarchisch oder netzwerkartig sein . Benutzern werden Teilmengen dieses logischen Modells zugewiesen, sogenannte externe Modelle (in einigen Quellen auch Subschemata genannt), die ihr Verständnis des Themenbereichs widerspiegeln. Externes Modell entspricht den Ansichten, die Benutzer basierend auf dem logischen Modell erhalten konzeptionelle Anforderungen spiegeln die Wahrnehmungen wider, die sich die Nutzer ursprünglich gewünscht hatten und die die Grundlage für die Entwicklung des konzeptionellen Modells bildeten. Das logische Modell wird in angezeigt physikalischer Speicher B. eine Diskette, ein Band oder ein anderes Speichermedium.

@ Physikalisches Modell , das die Platzierung von Daten, Zugriffsmethoden und Indizierungstechniken bestimmt, wird als internes Modell des Systems bezeichnet.

Aus Sicht der Anwendungsprogrammierung wird die Datenunabhängigkeit nicht durch die Programmiertechnik, sondern durch deren Disziplin bestimmt. Um beispielsweise zu vermeiden, dass die Anwendung bei jedem Systemwechsel neu kompiliert werden muss, wird empfohlen, im Programm keine Konstanten (konstante Datenwerte) zu definieren. Eine bessere Lösung besteht darin, Werte als Parameter an das Programm zu übergeben.

Alle aktuellen Anforderungen des Fachgebiets und die ihnen in der Entwurfsphase entsprechenden „verborgenen“ Anforderungen müssen sich im konzeptionellen Modell widerspiegeln. Natürlich ist es unmöglich, alle möglichen Nutzungen und Änderungen der Datenbank vorherzusehen. In den meisten Bereichen sind die zugrunde liegenden Daten, beispielsweise Objekte und ihre Beziehungen, jedoch relativ stabil. Lediglich die Informationsanforderungen ändern sich, also die Art und Weise, wie Daten zur Informationsbeschaffung genutzt werden.

Der Grad der Datenunabhängigkeit wird durch die sorgfältige Gestaltung der Datenbank bestimmt. Eine umfassende Analyse der Domänenobjekte und ihrer Beziehungen minimiert die Auswirkungen sich ändernder Datenanforderungen in einem Programm auf andere Programme. Darum geht es bei umfassender Datenunabhängigkeit.

3. Beziehungen im Modell

Eine Beziehung drückt eine Zuordnung oder Beziehung zwischen zwei Datensätzen aus. Es gibt Beziehungen vom Typ „ eins zu eins», « eins zu viele" Und "viel zu viel" Bei der betrachteten Aufgabe der Automatisierung der Verwaltung eines Autohauses erfolgt, wenn ein Kunde zum ersten Mal eine Bestellung zum Kauf eines Autos aufgibt, die Ersterfassung seiner Daten und Informationen über die getätigte Bestellung. Wenn der Kunde erneut eine Bestellung aufgibt, wird nur diese Bestellung registriert. Unabhängig davon, wie oft ein bestimmter Kunde Bestellungen aufgegeben hat, verfügt er über eine eindeutige Identifikationsnummer (eindeutiger Kundenschlüssel). Zu den Informationen über jeden Kunden gehören Name, Adresse, Telefon, Fax, Nachname, Vorname, Vatersname und Zeichen des Kunden juristische Person und beachten. Somit sind die Attribute des CLIENT-Objekts „EINZIGARTIGER CLIENT-SCHLÜSSEL“, „KUNDENNAME“, „KUNDENADRESSE“ usw. Das nächste für uns interessante Objekt ist das AUTOMODELL. Dieses Objekt hat die Attribute „EINZIGARTIGER MODELLSCHLÜSSEL“, „MODELLNAME“ usw. Das dritte betrachtete Objekt ist ORDNUNG. Seine Attribute sind „ORDER NUMBER“, „CUSTOMER KEY“ und „MODEL KEY“. Und das vierte fragliche Objekt ist der VERKÄUFER. Seine Attribute sind „EINZIGARTIGER VERKÄUFERSCHLÜSSEL“, „VERKÄUFERNAME“, „NACHNAME“ und „VATTERNAME“.

Eins-zu-eins-Beziehung (zwischen zwei Arten von Objekten)

Kehren wir gedanklich in die Zeit der planmäßigen Verteilungswirtschaft zurück. Nehmen wir an, dass ein Kunde zu einem bestimmten Zeitpunkt nur eine Bestellung aufgeben kann. In diesem Fall wird eine Beziehung zwischen den Objekten CLIENT und ORDER hergestellt. eins zu eins", angezeigt durch einzelne Pfeile, wie in Abb. 2.2,a.

Reis. 2.2. Beziehungen zwischen zwei Objekten: a) „eins zu eins“; b) „eins zu vielen“; c) „viele zu viele“

Reis. 2.3. Die Beziehung zwischen Daten in einer Eins-zu-Eins-Beziehung.

Eine Eins-zu-viele-Beziehung (zwischen zwei Arten von Objekten).

Zu einem bestimmten Zeitpunkt kann ein Kunde Eigentümer mehrerer Automodelle werden, während nicht mehrere Kunden dasselbe Auto besitzen können. Eine Eins-zu-viele-Beziehung kann durch einen einzelnen Pfeil in die eine Richtung und einen Doppelpfeil in die viele Richtung dargestellt werden, wie in Abbildung 1 dargestellt. 2.2, B.

In diesem Fall entspricht ein Datensatz des ersten Objekts (oft als übergeordnetes oder Hauptobjekt bezeichnet) mehreren Datensätzen des zweiten Objekts (untergeordnetes oder untergeordnetes Objekt). Eins-zu-viele-Beziehungen sind in der relationalen Datenbankentwicklung weit verbreitet. Das übergeordnete Objekt ist häufig ein Verzeichnis, und das untergeordnete Objekt speichert eindeutige Schlüssel für den Zugriff auf Verzeichniseinträge. In unserem Beispiel kann ein solches Verzeichnis durch das CLIENT-Objekt dargestellt werden, das Informationen über alle Clients speichert. Wenn wir auf einen Datensatz für einen bestimmten Kunden zugreifen, haben wir Zugriff auf eine Liste aller von ihm getätigten Käufe und Informationen darüber, welche im Objekt CAR MODEL gespeichert sind, wie in Abb. 2.4. Wenn es einige Datensätze im untergeordneten Objekt gibt, für die es keine entsprechenden Datensätze im CLIENT-Objekt gibt, werden wir sie nicht sehen. In diesem Fall soll das Objekt verwaiste (einsame) Datensätze enthalten. Das ist nicht akzeptabel, und in Zukunft werden Sie lernen, wie Sie solche Situationen vermeiden können.

Reis. 2.4. Die Beziehung zwischen Daten in einer Eins-zu-Viele-Beziehung.

Wenn wir uns die Datensätze des CAR MODEL-Objekts ansehen, können wir im CLIENT-Objekt Daten über den Kunden erhalten, der dieses Objekt gekauft hat Auto (siehe Abb. 2.4). Bitte beachten Sie, dass wir keine Kundeninformationen zu verlorenen Unterlagen erhalten.

Eine Viele-zu-Viele-Beziehung (zwischen zwei Arten von Objekten).

In diesem Beispiel kann jeder Verkäufer mehrere Kunden bedienen. Wenn andererseits ein Auto zu unterschiedlichen Zeiten gekauft wird, kann es sein, dass jeder Kunde von verschiedenen Verkäufern bedient wird. Zwischen den Objekten CLIENT und SELLER besteht eine Viele-zu-Viele-Beziehung. Dieser Zusammenhang ist angegeben Doppelpfeile, wie in Abb. 2.2, c.

In Abb. In Abb. 2.5 zeigt ein Diagramm, nach dem die Daten in diesem Fall miteinander verbunden werden. Indem wir uns die Daten im CLIENT-Objekt ansehen, können wir herausfinden, welche Verkäufer einen bestimmten Kunden bedient haben. Allerdings müssen wir in diesem Fall für jeden Verkäufer im Objekt SELLER mehrere Datensätze erstellen. Jede Zeile entspricht jedem Kundendienst des Verkäufers. Mit diesem Ansatz werden wir vor ernsthaften Problemen stehen. Beispielsweise können wir nicht für jeden Verkäufer einen eindeutigen Schlüssel in das SELLER-Objekt eingeben, da ein Verkäufer zwangsläufig mehrere Kunden bedienen wird und wir dann mehrere Datensätze für denselben Verkäufer haben.

Reis. 2.5. Beziehung zwischen Daten in einer Viele-zu-Viele-Beziehung

Gemäß der relationalen Datenbanktheorie sind zum Speichern einer Viele-zu-Viele-Beziehung drei Objekte erforderlich: eines für jede Entität und eines zum Speichern der Beziehungen zwischen ihnen (ein Zwischenobjekt). Das Zwischenobjekt enthält die Bezeichner verwandter Objekte, wie in Abb. 2.6.

Reis. 2.6. Darstellung der Beziehung zwischen Daten in einer Viele-zu-Viele-Beziehung mithilfe eines Zwischenobjekts

Beziehungen zwischen Objekten sind Teil des konzeptionellen Modells und müssen in der Datenbank abgebildet werden. Neben Beziehungen zwischen Objekten gibt es auch Beziehungen zwischen Objektattributen. Es wird außerdem zwischen Eins-zu-Eins-, Eins-zu-Viele- und Viele-zu-Viele-Beziehungen unterschieden.

Eins-zu-eins-Beziehung (zwischen zwei Attributen)

Wir gehen davon aus, dass der Schlüssel (die Nummer) des Kunden seine eindeutige Kennung ist, das heißt, er ändert sich nicht bei nachfolgenden Bestellungen, die von diesem Kunden eingehen. Wenn neben der Kundennummer noch eine weitere eindeutige Kennung (z. B. eine Passnummer) in der Datenbank gespeichert ist, besteht zwischen diesen beiden eindeutigen Kennungen eine Eins-zu-eins-Beziehung. In Abb. 2.7a dieser Zusammenhang ist durch einzelne Pfeile angedeutet.

Eins-zu-viele-Beziehung (zwischen zwei Attributen)

Kundenname und Kundennummer existieren zusammen. Kunden mit gleiche Namen Es mag viele geben, aber sie haben alle unterschiedliche Nummern. Jedem Kunden wird eine eindeutige Nummer zugewiesen. Dies bedeutet, dass einer bestimmten Kundennummer nur ein Name zugeordnet ist. Eine „eins-zu-viele“-Beziehung wird durch einen einzelnen Pfeil in Richtung „eins“ und einen Doppelpfeil in Richtung „viele“ angezeigt (Abb. 2.7, b).

Viele-zu-viele-Beziehung (zwischen zwei Attributen)

Mehrere Kunden mit demselben Namen könnten von mehreren Verkäufern betreut werden. Mehrere Verkäufer mit demselben Namen könnten Bestellungen von mehreren Kunden erhalten. Zwischen den Attributen „Kundenname“ und „Lieferantenname“ besteht eine Viele-zu-Viele-Beziehung. Wir kennzeichnen diesen Zusammenhang mit Doppelpfeilen (Abb. 2.7c).).

A)

B)

V)

Reis. 2.7. Beziehungen zwischen zwei Attributen:
a) Eins-zu-eins-Beziehung; b) Eins-zu-Viele-Beziehung
» c) Viele-zu-viele-Beziehung»

Arten von Datenmodellen

In den frühen 60er Jahren wurden hierarchische und Netzwerkdatenmodelle erstmals in Datenbankverwaltungssystemen eingesetzt. In den frühen 70er Jahren wurde ein relationales Datenmodell vorgeschlagen. Die drei Modelle unterscheiden sich hauptsächlich in der Art und Weise, wie sie Beziehungen zwischen Objekten darstellen.

Das hierarchische Datenmodell basiert auf dem Prinzip einer Hierarchie von Objekttypen, d. h. ein Objekttyp ist der Hauptobjekttyp und der Rest, der sich auf niedrigeren Ebenen der Hierarchie befindet, ist untergeordnet (Abb. 2.8). Zwischen den Master- und Slave-Objekten wird eine Eins-zu-Viele-Beziehung hergestellt. Mit anderen Worten: Für einen bestimmten Hauptobjekttyp gibt es mehrere untergeordnete Objekttypen. Gleichzeitig kann es zu jeder Instanz des Hauptobjekts mehrere Instanzen untergeordneter Objekttypen geben. Somit ähneln die Beziehungen zwischen Objekten den Beziehungen in einem Stammbaum, mit einer Ausnahme: Für jeden untergeordneten (untergeordneten) Objekttyp kann es nur einen übergeordneten (Haupt-)Objekttyp geben. An Reis. 2.8 Knoten und Zweige bilden eine hierarchische Baumstruktur. Ein Knoten ist eine Sammlung von Attributen, die ein Objekt beschreiben. Der höchste Knoten in der Hierarchie wird Wurzelknoten genannt (dies ist der Hauptobjekttyp). Der Wurzelknoten befindet sich auf der ersten Ebene. Abhängige Knoten (untergeordnete Objekttypen) befinden sich auf der zweiten, dritten usw. Ebene.

Reis. 2.8. Hierarchisches Datenmodelldiagramm.

Im Netzwerkdatenmodell sind die Konzepte von Master- und Slave-Objekten etwas erweitert. Jedes Objekt kann sowohl Master als auch Slave sein (im Netzwerkmodell wird das Master-Objekt mit dem Begriff „Set-Eigentümer“ und der Slave mit dem Begriff „Set-Mitglied“ bezeichnet). Dasselbe Objekt kann gleichzeitig Eigentümer und Mitglied einer Menge sein. Das bedeutet, dass jedes Objekt an beliebig vielen Beziehungen teilnehmen kann. Das Diagramm des Netzwerkmodells ist in Abb. 2.9 dargestellt.

Abb.2.9. Diagramm des Netzwerkdatenmodells.

Im relationalen Datenmodell werden Objekte und Beziehungen zwischen ihnen mithilfe von Tabellen dargestellt, wie in Abb. 2.10. Auch Beziehungen gelten als Objekte. Jede Tabelle stellt ein Objekt dar und besteht aus Zeilen und Spalten. In einer relationalen Datenbank muss jede Tabelle einen Primärschlüssel haben ( Schlüsselelement) – ein Feld oder eine Kombination von Feldern, das jede Zeile in einer Tabelle eindeutig identifiziert. Aufgrund seiner Einfachheit und Natürlichkeit in der Darstellung hat sich das relationale Modell in DBMS für Personalcomputer am weitesten verbreitet.

Reis. 2.10. Diagramm des relationalen Datenmodells.

Die zweite Phase der Analyse des Themenbereichs besteht aus der Auswahl von Informationsobjekten, der Festlegung der erforderlichen Eigenschaften für jedes Objekt, der Identifizierung von Verbindungen zwischen Objekten, der Bestimmung der den Informationsobjekten auferlegten Einschränkungen, der Arten der Verbindungen zwischen ihnen und der Eigenschaften von Informationsobjekten .

Bei der Auswahl von Informationsobjekten müssen Sie eine Reihe von Fragen beantworten:

1. In welche Tabellen können die in der Datenbank zu speichernden Daten aufgeteilt werden?

2. Welchen Namen kann man jeder Tabelle geben?

3. Was sind die interessantesten Eigenschaften (aus Nutzersicht)?

4. Welche Namen können den ausgewählten Merkmalen zugeordnet werden?

In unserem Fall sollen folgende Tabellen erstellt werden (Abbildung 4):


Lassen Sie uns die Verbindungen zwischen Informationsobjekten hervorheben (Abb. 5)



Dabei müssen folgende Fragen beantwortet werden:

1. Welche Arten von Verbindungen zwischen Informationsobjekten?

2. Welchen Namen kann man jeder Beziehungsart geben?

3. Welche Anschlussarten gibt es, die später genutzt werden können?

Der Versuch, Beschränkungen für Objekte, ihre Eigenschaften und Verbindungen festzulegen, führt zu der Notwendigkeit, die folgenden Fragen zu beantworten:

1. Wie groß ist der Wertebereich für numerische Merkmale?

2. Welche funktionalen Abhängigkeiten bestehen zwischen den Merkmalen eines Informationsobjekts?

3. Welche Art der Darstellung entspricht dem jeweiligen Beziehungstyp?

Beim Entwurf einer Datenbank gibt es Beziehungen zwischen Informationsobjekten dreier Typen: „eins zu eins“, „eins zu viele“, „viele zu viele“ (Abb. 6).


Zum Beispiel:

Erstellen eines konzeptionellen Modells

In einfachen Fällen werden traditionelle Methoden der Aggregation und Generalisierung verwendet, um ein konzeptionelles Diagramm zu erstellen. Bei der Aggregation werden Informationsobjekte (Datenelemente) entsprechend den semantischen Beziehungen zwischen Objekten zu einem zusammengefasst. Beispielsweise findet in Raum Nr. 7 ab 9:30 Uhr eine Geschichtsstunde in der 10. Klasse statt. Mithilfe der Aggregationsmethode erstellen wir ein Informationsobjekt (Entität) SCHEDULE mit den folgenden Attributen: „Klasse“, „Betreff“, „Büro“, „Zeit“. Bei der Generalisierung werden Informationsobjekte (Datenelemente) zu einem generischen Objekt zusammengefasst (Abb. 7):

Die Wahl des Modells wird in erster Linie durch die Art des Fachgebiets und die Anforderungen an die Datenbank bestimmt. Ein weiterer wichtiger Umstand ist die Unabhängigkeit des konzeptionellen Modells vom DBMS, das nach der Erstellung des konzeptionellen Diagramms ausgewählt werden muss.

Entity-Relationship-Modelle, die die Möglichkeit bieten, die Struktur und Einschränkungen der realen Welt darzustellen und sie dann entsprechend den Fähigkeiten industrieller DBMS zu transformieren, sind weit verbreitet.

Unter der Essenz wird der Hauptinhalt des Phänomens, Prozesses oder Objekts verstanden, über den Informationen für die Datenbank gesammelt werden. Eine Entität kann ein Ort, eine Sache, eine Person, ein Phänomen usw. sein. Dabei wird zwischen einem Entitätstyp und einer Entitätsinstanz unterschieden. Unter einem Entitätstyp versteht man üblicherweise eine Menge homogener Objekte, die als Ganzes agieren. Das Konzept der „Entitätsinstanz“ bezieht sich auf ein bestimmtes Element. Zum Beispiel:

Entitätstyp – Student

Entitätsinstanz – Ivanov, Petrov, Sidorov usw.

In unserem Beispiel sind Schule, Klasse, Fächer, Schüler, Lehrer und Noten Entitäten. Lassen Sie uns die Verbindungen zwischen Entitäten analysieren (Abb. 8).

Jetzt können Sie mit dem Entwurf des Informationsdiagramms (Konzeptdiagramm) der Datenbank fortfahren (Entitätsattribute werden im Diagramm nicht angezeigt) (Abb. 9).


gehört Die Schule
Klasse Studien Student
funktioniert Studien
Lehrer Lehrt Artikel
Prüfung
Stellungnahme

Logisches Design

Logisches Design ist ein notwendiger Schritt beim Erstellen einer Datenbank. Die Hauptaufgabe des logischen Designs ist die Entwicklung eines logischen Diagramms, das sich auf das ausgewählte Datenbankverwaltungssystem konzentriert. Der logische Designprozess besteht aus den folgenden Schritten:

1. Auswahl eines bestimmten DBMS;

2. Zuordnung eines konzeptionellen Diagramms zu einem logischen Diagramm;

3. Auswahl einer Datenbearbeitungssprache.

Auswahl eines bestimmten DBMS

Eines der Hauptkriterien für die Auswahl eines DBMS ist die Beurteilung, wie effektiv das vom System unterstützte interne Datenmodell das konzeptionelle Schema beschreiben kann. Datenbankverwaltungssysteme mit Schwerpunkt auf persönliche Computer, unterstützen typischerweise relationale oder Netzwerkmodell Daten. Die überwiegende Mehrheit der modernen DBMS ist relational.

Der Entwurf von Datenbanken auf Basis des relationalen Modells bietet gegenüber anderen Modellen eine Reihe wichtiger Vorteile.

· Unabhängigkeit der logischen Struktur von der physischen und Benutzerdarstellung.

· Flexibilität der Datenbankstruktur – Designlösungen schränken die Fähigkeit des Datenbankentwicklers, in Zukunft eine Vielzahl von Abfragen durchzuführen, nicht ein.

Da das relationale Modell keine Beschreibung aller möglichen Beziehungen zwischen Daten erfordert, kann der Entwickler anschließend Abfragen zu allen in der Datenbank enthaltenen logischen Beziehungen stellen und nicht nur zu den ursprünglich geplanten.

Arten von Beziehungen zwischen Domänenobjekten

Es gibt vier Arten von Beziehungen, die auf Multiplizität basieren: „Eins-zu-Eins“, „Eins-zu-Viele“, „Viele-zu-Viele“, „Viele-zu-Eins“.

Eine Eins-zu-Eins-Beziehung (1:1) besteht, wenn eine Instanz eines Objekts mit einer einzelnen Instanz eines anderen Objekts verknüpft ist. Die Beziehung ist sowohl von links nach rechts als auch von rechts nach links eindeutig.

führt

Unternehmensdirektor

Eine Eins-zu-viele-Beziehung (1:M) liegt vor, wenn eine Instanz eines ersten Objekts mit einer (oder mehreren) Instanzen eines zweiten Objekts verknüpft ist, jede Instanz des zweiten Objekts jedoch nur mit einer Instanz des ersten Objekts verknüpft ist . Die Beziehung ist von rechts nach links eindeutig.

Besteht aus

Stadtteil

Eine Viele-zu-Viele-Beziehung (M:M) liegt vor, wenn eine Instanz des ersten Objekts einer oder mehreren Instanzen des zweiten und jede Instanz des zweiten Objekts einer oder mehreren Instanzen des ersten Objekts zugeordnet ist.

Student (Nachname, Notenbuch-Nr. Fakultät) Fach (Name, Stundenzahl)

Eine Viele-zu-Eins-Beziehung (M:1) ähnelt einer Eins-zu-Viele-Beziehung. Die Beziehung ist nur von links nach rechts eindeutig.

Nachname des Schülers (M:1) Gruppennummer

Konzeptionelles Modell. Ein Modell von Objekten mit sie beschreibenden Attributen und Beziehungen zwischen ihnen wird aufgerufen Konzeptmodell. Dieses Modell stellt Objekte und ihre Beziehungen dar, ohne anzugeben, wie sie physisch gespeichert werden.

Die grafische Darstellung erfolgt in Form eines speziellen Diagramms, das vom amerikanischen Datenbankspezialisten Charles Bachman vorgeschlagen wurde. In Bachmann-Diagrammen werden Objekte durch die Eckpunkte eines bestimmten mathematischen Graphen dargestellt und Verbindungen werden durch Bögen des Graphen dargestellt. Betrachten wir zum Beispiel das Procurement Data Model (siehe Abb. 48).

Reis. 48 Beispiel für die Gestaltung eines konzeptionellen Modells

Das Modell besteht aus drei Objekten: Lieferant, Bestellung, Produkt. Die zwischen den Objekten Lieferant und Bestellung bestehende Beziehung hat die Potenz von Eins-zu-Viele, da jede Bestellung an einen Lieferanten gesendet wird, aber mehrere Bestellungen an einen bestimmten Lieferanten gesendet werden können Anbieter. Die Beziehung zwischen den Objekten „Order“ und „Product“ hat eine Viele-zu-Viele-Leistung, da eine Bestellung mehrere Produkte enthält und ein Produkt in mehreren Bestellungen vorkommen kann.

Strukturelemente der Datenbank

Bei der Beschreibung eines Datenobjekts müssen zwei Komponenten unterschieden werden: Struktur und Instanz.

Struktur– eine Liste von Objektattributen und Eigenschaften der Attribute.

Beispiel– eine Reihe von Attributwerten.

Die Struktur ändert sich äußerst selten. Die Instanz kann sich ändern.

Bei der Speicherung auf einem Computer entspricht eine Datenbank einer Gruppe von Dateien und Ordnern, und eine Datei entspricht einer Reihe von Objekten. Für jedes Objekt gibt es einen entsprechenden Eintrag in der Datei. Für jedes Attribut gibt es ein entsprechendes Feld im Datensatz.

Zur Beschreibung des Attributs werden folgende Merkmale verwendet:

1. Name, zum Beispiel nContract, cStudent;

2. Typ, zum Beispiel symbolisch, numerisch;

3. Länge, zum Beispiel 15 Byte;

4. Präzision für numerische Daten.

5. Beschreibung, Kommentar;

6. Bildformat auf Bildschirm und Papier;

7. Hinweis;

8. Eingabeformat;

9. Anfangswert;

10. Wertebereich.

Schlüssel ist ein Mittel zum Organisieren von Objekten in einer Menge. Der Schlüssel enthält Schlüsselausdruck, bestehend aus Objektattributen. Mit zunehmendem Wert des Schlüsselausdrucks werden Objekte zur Ansicht und Verarbeitung präsentiert.

Sie können mehrere Schlüssel für einen Satz angeben. Beispielsweise können Sie für den Satz „Mitarbeiter“ den Schlüssel nach dem Alphabet der Nachnamen festlegen, die Mitarbeiter werden in alphabetischer Reihenfolge angezeigt.

Der Schlüssel heißt primär, wenn ein Wert seines Ausdrucks 0 oder 1 Objekt aus der Menge auswählt. Für die Rekrutierung von Mitarbeitern ist beispielsweise der Schlüssel „Nach Personalnummer“ primär, da auf Basis eines Wertes der Personalnummer entweder kein oder nur ein Mitarbeiter zugeordnet wird.

Der Schlüssel heißt sekundär, wenn ein Wert seines Ausdrucks 0 oder mehr Objekte aus der Menge identifiziert. Beispielsweise ist der Schlüssel zur Mitarbeiterrekrutierung, der Schlüssel „Alphabetisch nach Nachnamen“, zweitrangig, da es unter den Mitarbeitern möglicherweise Namensvetter gibt.

Nach dem Differenzaxiom hat jede Menge einen Primärschlüssel. Im Extremfall umfasst sein Ausdruck alle Attribute des Objekts in der Menge.

Eine gute Vorgehensweise besteht darin, ein künstliches Attribut für das Datenobjekt einzuführen, „Sequenznummer im Satz“, das automatisch zugewiesen und eindeutig ist. Der Schlüssel für dieses Attribut heißt Surrogat.

Beachten Sie, dass die Konzepte des Primär- und Sekundärschlüssels nicht von der Anzahl und den Werten der Objekte in der Menge abhängen. Primär- und Sekundärschlüssel gelten für leere Mengen.

Es gebe n Mengen von Objekten E 1, E 2, ..., E n.

Kommunikation heißt eine Menge von Folgen von Objekten (е i 1, е i 2, …, е i n), wobei е i 1 О Е 1, е i 2 О Е 2, …, е i n О Е n.

Mithilfe von Verbindungen werden Objektmengen zu einer einzigen Informationsstruktur zusammengefasst.

Es gibt drei Arten von Verbindungen zwischen zwei Objektmengen (n=2):

1. eins zu eins (1:1);



2. eins zu viele (1:M);

3. viele zu viele (M:N).

"eins zu eins", Wenn Sie für jedes Objekt aus dem ersten Satz angeben können 0 oder 1 Objekt aus der zweiten Menge und für jedes Objekt aus der zweiten Menge können Sie angeben 0 oder 1 Objekt aus dem ersten Satz.

Beispiele für 1:1-Beziehungen sind Verbindungen zwischen:

· Schüler- und Notenbücher,

zwischen Staaten und Währungen,

zwischen Offizieren und Dienstwaffen,

· zwischen Staatsbürgern und ausländischen Pässen. Jeder Schüler hat entweder kein Notenbuch oder nur eines.

Für jeden Datensatz ist entweder der Student nicht angegeben, oder es ist nur einer vorhanden.

Die Verbindung zwischen zwei Mengen E 1 und E 2 ist vom Typ „eins zu viele“ 0 oder mehr 0 oder 1 Objekt aus dem ersten Satz.

Beispiele für 1:M-Verbindungen sind Verbindungen zwischen

· Banken und Einlagen,

· Einlagen und Beiträge,

zwischen Gruppen und Studierenden,

zwischen Abteilungen und Mitarbeitern,

zwischen Anweisungen und Anweisungszeilen,

· zwischen Kunden und Anfragen.

Jede Bank hat entweder keine Einlagen (die Bank hat noch nicht eröffnet) oder möglicherweise viele Einlagen. Für jede Einzahlung ist entweder die Bank nicht angegeben, oder es gibt nur eine.

Die Verbindung zwischen zwei Mengen E 1 und E 2 ist vom Typ "viel zu viel", wenn Sie für jedes Objekt aus der ersten Menge angeben können 0 oder mehr Objekte aus der zweiten Menge und für jedes Objekt aus der zweiten Menge können Sie angeben 0 oder mehr Objekte aus dem ersten Satz.

Beispiele für M:N-Beziehungen sind Beziehungen zwischen

· Produkte und Länder,

zwischen Studierenden und Disziplinen,

zwischen Mitarbeitern und Projekten,

zwischen Bestellungen und Produkten,

zwischen Geschäften und Kunden.

Jedes Produkt kann aus vielen oder gar keinem Land stammen. Jedes Land liefert möglicherweise viele Produkte und liefert keine.

Grafisch werden Verbindungen durch Pfeile dargestellt (Abb. 4.5).

In echten DBMS ist nur eine Art der Kommunikation implementiert – eins zu viele.

Aus der 1:M-Beziehung ergibt sich durch Begrenzung die 1:1-Beziehung.

Um die M:N-Beziehung zu implementieren, wird ein neuer Satz von Objekten eingeführt und zwei 1:M-Beziehungen verwendet.

Beispielsweise wird die Beziehung zwischen Ländern und Produkten vom Typ M:N mithilfe des Datensatzes „Versorgungen“ ermittelt (Abb. 4.6).

Alle Objekte sind aktiv.

Benutzerdefinierte Steuerung von Fenstergruppen.

Aufgabenorientierte Fenstertypen.

Sofortige Aufzeichnung von Änderungen.

Dynamische Symbole, die den Zustand des Objekts widerspiegeln.

Direkte Manipulation.

Objekte kombinieren.

Zusammensetzung von Objekten und Behältern.

Mehrfache konsistente Betrachtung von Objekten.

Oben besprochene Funktionen grafische Oberflächen sowie die ihrer Implementierung zugrunde liegende DCD-Technologie erfordern die Verwendung eines objektorientierten Ansatzes für das GUI-Design. Dieser Ansatz beinhaltet die Verwendung von Analogien zwischen Softwareobjekten und realen Objekten. Aus der Sicht der Benutzeroberfläche sind Objekte nicht nur Dateien oder Symbole, sondern alle Geräte zum Speichern und Verarbeiten von Informationen, einschließlich Zellen, Absätzen, Symbolen usw. sowie der Dokumente, in denen sie sich befinden.

Objekte, unabhängig davon, ob sie zur realen Welt gehören oder eine Computerverkörperung haben, haben bestimmte Eigenschaften, die uns helfen zu verstehen, was sie sind und wie sie sich in bestimmten Situationen verhalten. Die folgenden Konzepte beschreiben die Hauptaspekte und Eigenschaften von Objekten, die eine Computerverkörperung haben.

Objekteigenschaften. Objekte verfügen über bestimmte Merkmale oder Attribute, sogenannte Eigenschaften, die ihre Darstellung oder mögliche Zustände (z. B. Farbe, Größe, Änderungsdatum) definieren. Eigenschaften sind nicht auf die äußeren oder sichtbaren Merkmale eines Objekts beschränkt. Sie können ihre interne Organisation oder den aktuellen Zustand des Objekts widerspiegeln.

Operationen an Objekten. Alle Aktionen, die an (oder an) einem Objekt ausgeführt werden können, gelten als gültige Operationen. Beispiele für Operationen sind das Verschieben oder Kopieren eines Objekts. Der Benutzer kann mithilfe bestimmter von der Schnittstelle bereitgestellter Mechanismen Operationen an Objekten ausführen ( Befehlssteuerung oder direkte Manipulation).

Kommunikation (Beziehungen) zwischen Objekten. Jedes Objekt interagiert auf die eine oder andere Weise mit anderen Objekten. In vielen Fällen können Beziehungen zwischen Objekten als eine Art Beziehung beschrieben werden.

Arten von Verbindungen zwischen Objekten.

Die häufigsten Arten von Beziehungen sind Sammlungen, Einschränkungen und Verbundbeziehungen.

Bausatz ist die einfachste Art von Beziehung, die das Vorhandensein bestimmter gemeinsamer Eigenschaften zwischen Objekten widerspiegelt. Abfrageergebnisse (Mustersuche) oder mehrere Objektauswahloperationen – Anwendungsbeispiele dieser Art Beziehung. Ein wichtiger Vorteil dieser Art von Beziehung besteht darin, dass Sie Vorgänge angeben können, die auf einen bestimmten Satz von Objekten angewendet werden sollen.

Einen Verband spiegelt eine engere Beziehung zwischen Objekten wider, bei der sich eine Änderung an einem Objekt auf ein anderes Objekt in der Menge auswirkt. Das einfachste Beispiel einer solchen Beziehung ist die Änderung des Formats einer angrenzenden Seite beim Hinzufügen von Text auf der vorherigen Seite.

Komposition tritt auf, wenn die Aggregation mehrerer Objekte als neues Objekt mit eigenen Eigenschaften und gültigen Operationen betrachtet werden kann. Eine Zellspalte in einer Tabelle und ein Absatz im Text sind Beispiele für Kompositionen.

Eine weitere häufige Art der Beziehung zwischen Objekten ist ein Container.

Container ist ein Objekt, das andere Objekte enthält (z. B. kann ein Bild in einem Dokument oder ein Dokument in einem Ordner als Teil des Inhalts des entsprechenden Containers betrachtet werden). Containereigenschaften wirken sich häufig auf das Verhalten seines Inhalts aus. Dieser Einfluss kann darin bestehen, einige Eigenschaften der darin enthaltenen Objekte zu erweitern oder zu unterdrücken oder die Liste der zulässigen Operationen zu ändern. Darüber hinaus steuert der Container den Zugriff auf seinen Inhalt sowie die Typkonvertierung (Formatkonvertierung) des darin enthaltenen Objekts. Dies kann sich insbesondere auf das Ergebnis des Sendens eines Objekts von einem Container in einen anderen auswirken.

Die oben diskutierten Aspekte erfordern die Zuordnung jedes Objekts zu dem einen oder anderen Typ (Klasse) von Objekten. Objekte desselben Typs haben ähnliche Eigenschaften und Verhaltensweisen.

Die grundlegenden Schnittstellenobjekttypen bilden die grundlegenden Klassen aller von bereitgestellten Objekte Betriebssystem. Es gibt drei Haupttypen von Objekten: Datenobjekte, Containerobjekte und Geräteobjekte.

Viele Objekte verfügen über Merkmale, die in mehr als eine Klasse fallen (Beispiel: Posteingang: Container- und Geräteeigenschaften). Daher ist ein gutes Verständnis der Schnittstellenobjektklassen und ihres Verhaltens erforderlich. Objekte müssen die Erwartungen der Benutzer an die von ihnen ausgeführten Aktionen erfüllen, d. h. bestimmen, welche Ansichten sie anzeigen und ändern können. Containerobjekte müssen Ansichten bereitstellen, die mit anderen Containern konsistent sind; Geräteobjekte müssen Ansichten bereitstellen, die mit anderen Containern konsistent sind. Dieses Gerät und kompatibel mit anderen.

Datenobjekte stellen Benutzern Informationen zur Verfügung. Sie können jede Art von Informationen darstellen, z. B. Text, Tabellenkalkulationen, Bilder, Musik, aufgezeichnete Sprache, Videos, Animationen oder eine beliebige Kombination davon. Da Datenobjekte typischerweise produktorientiert sind, definieren Designrichtlinien keine spezifischen Datenobjekte. Dies ist die Aufgabe von Programmdesignern.