SteffiMichi Geschrieben 28. September 2001 Teilen Geschrieben 28. September 2001 Hi @all! Ich bräuchte mal dringend allgemeine Informationen über Datenbanken! Also Was ist eine Datenbank?, wie funzt eine Datenbank?, Was gibt es für Datenbanken und so weiter und so fort! Über Links zu Sites mit massig Infos oder so, wär ich sehr dankbar! Danke schon mal! Mfg StMi Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Spike Geschrieben 28. September 2001 Teilen Geschrieben 28. September 2001 http://www.google.de/search?hl=de&q=%2BDatenbank+%2BFunktion&btnG=Google-Suche&meta= Bitte Suchmaschinen wirken Wunder ... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
etu Geschrieben 29. September 2001 Teilen Geschrieben 29. September 2001 Wenn Du ein paar gute Links gefunden hast, stell sie doch bitte ins Forum!!! Viele Leute freuen sich, wenn sie nicht selber suchen müssen Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 30. September 2001 Autor Teilen Geschrieben 30. September 2001 Danke für die fertige Suchmaschine, die enthält auch ettliche Infos, nur weiß ich net so genau, wie ich diese verwerten soll! Habe das erste Mal mit Datenbanken zu tun (erstes LJ FI/AE) und weiß auch net, was der Ausbilder hören will! Vielleicht kennt das schon Jemand und kann mir helfen? Gruß StMi Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Eva Geschrieben 30. September 2001 Teilen Geschrieben 30. September 2001 Hi SteffiMichi, also das wird meistens im Zusammenhang mit DB geschult/gelernt ... Vielleicht findest du ja einen Link dazu, ich hab leider nur einen gefunden Datenbank --------- Eine DB ist eine integrierte Ansammlung von Daten, die allen Benutzern eines Anwendungsbereichs als gemeinsame Basis aktueller Informationen dient. Unterschiede Dateisystem und DB (wird oft benutzt ) Ersmal kann man nach dem Modell eine DB unterscheiden ----------------------------------------------------- Hierarchisches Modell Netzwerkmodell Relationenmodell(das wohl am meisten benutzte ) Objektorientiertes Modell Dann würd ich dir raten vielleicht das Dreischichtenkonzept anzuschauen: ----------------------------------------------------- Externes Schema Internes Schema Konzeptioneles Schema oder die Sichten (externe Sicht, logische Gesamtsicht, interne Sicht) Schau mal was du dazu findest Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Althea.Vestrit Geschrieben 10. Oktober 2001 Teilen Geschrieben 10. Oktober 2001 Hallo, hier findest du zwei Vorträge zu relationalen Datenbanken: http://www.ks2-hanau.de/services.htm Beitrag am 15.09.2000 von Herrn Matzner hinzugefügt. Ich hoffe es hilft dir etwas. Althea Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MoRpH2102 Geschrieben 12. Oktober 2001 Teilen Geschrieben 12. Oktober 2001 danke althea die beiden präsentationene haben mir sehr geholfen trotzdem kapirt ich dass mit den datenbanken nicht so ganz aber kann auch nicht sagen was ich nich weiß is komisch aber is so Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
JoelH Geschrieben 12. Oktober 2001 Teilen Geschrieben 12. Oktober 2001 hmm, was soll man da sagen ? Naj es gibt DBs wie Sand am Meer, irgendwie kann ich mich an Früher erinnern da war dbase das Maß aller dinge, das hat sich geändert, naaj momentan sind relationale DBs an der Macht obwohl OODBs nach vorne dringen. Naja aber wie auch immer, für den anwender zählt leistung , egal wie sie erzielt wird, bekannte DBs sin Oracle, MSSQL Server von MS, naja oder MySQL oder Postgres oder Sybase .... Das ist alles Ansichtssache , im Webservergeschäft ist woh MySQL die Numer eins, nicht weil sie am leistungsfähigsten ist sondern wie sie super wiet verbreitet ist und die genialste Webanbindung hat dank php . Naja und da beides mit dem meist verbreitesten Webserver der Welt zusammmen arbeitet ist WAMp oder LAMP das genialste System schlechthin ! Also Linux,Apache,MySql,Php bzw. Windows,Apache... Naja wenn du fit werden willst im bezug auf relationale DBs dann beschränke dich nicht auf eine , bzw. lerne gut SQL, das ist der schlüssel zu allen ! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MoRpH2102 Geschrieben 14. Oktober 2001 Teilen Geschrieben 14. Oktober 2001 ich denke ich kann meine frage jetzt kongretisieren, wie sollte ich eine db aufbauen also von der logik her ich benötige n beispiel mit erklärung Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SAS_Kind Geschrieben 15. Oktober 2001 Teilen Geschrieben 15. Oktober 2001 Schau mal hier: http://www.eifelsurf.de/fi99a/download/db.zip (ca 3 MB) Ich hoffe das hilft dir etwas weiter Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SAS_Kind Geschrieben 15. Oktober 2001 Teilen Geschrieben 15. Oktober 2001 Hier findest du auch noch etwas zu diesem Bereich http://www.issklar.de/___eBook_s/body____ebook_s.html Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 18. Oktober 2001 Teilen Geschrieben 18. Oktober 2001 Hi, StMi! Haben Dir die Links schon weitergeholfen? Ich muß zugeben, ich habe sie bisher nicht betrachtet... Wir haben ja alle einmal angefangen, und ich weiß nicht wo jetzt Dein Kenntnisstand liegt und ob die Antworten der Links wirklich bei Adam&Eva beginnen (und ob das überhaupt nötig ist). Ich fang mal kurz und knapp an: Du/Ihr könnt dann ja hier das vorhandene Interesse kundtun, auf dem folgenden Wege weiterzuverfahren: Zu Deiner Frage "Was ist eine Datenbank?" Also: Eine Datenbank ist erst mal (für den Anfang) nichts weiter als eine mehr oder weniger große Liste. In der Literatur steht:"...die Anordnung der Zeilen und Spalten ist willkürlich." Das heißt nicht, daß man Zeilen UND Spalten miteinander mischen darf, sondern die Reihenfolge der Zeilen (der Datensätze) für sich und die Reihenfolge der Spalten (Datenfeldbeschriftungen) für sich ist egal. Ob in den Spalten erst der Nachname kommt und dann der Vorname oder umgekert ist aus Datenbanksicht egal. Und ob in den Zeilen erst Abel mit (z.B.) seinen Anschriften-Feldern kommt oder erst Bebel mit den zu ihm/ihr gehörenden, ist aus Datenbanksicht ebenfalls egal. Soviel für heute (oder bei Nichtgefallen für sehr, sehr lange Zeit) Gruß und weiterhin viel Spaß piomode1 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 19. Oktober 2001 Autor Teilen Geschrieben 19. Oktober 2001 Danke, danke! Das hilft mir schon weiter! Obwohl ich sicherlich schon einige Vorkenntnisse im Computerbereich habe, habe ich mit Datenbanken fast noch nie gearbeitet (außer mit Works in d. Schule :-) ) Deshalb bin ich sehr dankbar, wenn man da beim Urschleim beginnt, schließlich will ich etwas lernen! Im Moment habe ich einen Block Schule und deshalb weiß ich nicht mal genau, was ich eigentlich wissen will! Einfach mal weitermachen! Danke! Gruß StMi Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 21. Oktober 2001 Teilen Geschrieben 21. Oktober 2001 Hi StMi! Hier kommt ein neues Kapitel: Stell Dir eine Liste vor, die besteht aus Personalnummer, Nachnamen, Abteilung, Raumnummer, Gehalt. Sogenannte Abfragen (genaueres dazu später) ermöglichen es einem, Informationen aus dieser Liste zu ziehen. Z.B.: Wieviele Mitarbeiter gibt es? Wenn nun alle Daten in einer Tabelle stehen, ergibt sich folgendes 'Problem': Wenn eine Abteilung in einen anderen Raum umzieht, müssen alle Mitarbeiter dieser Abteilung herausgesucht werden, und für jeden Mitarbeiter muß die neue Raumnummer erfaßt werden. Daraus ergeben sich zwei mögliche Fehlerquellen. 1) Es werden Mitarbeiter 'übersehen'. 2) es werden für einige Mitarbeiter vom Anwender falsche Raumnummern vergeben. Hier gehe ich davon aus, daß eine Abteilung zu jedem Zeitpunkt nur genau einen Raum (aber nicht unbedingt den gesamten) belegt. Und nun kommt die Idee der relationen Datenbanken: Da die Raumnummer unbedingt abhängig vom Abteilungsnamen ist und mehrere (Datenbank: beliebig viele. Realität: bis der Raum voll ist) Mitarbeiter in einer Abteilung arbeiten können, wird die Tabelle gesplittet in zwei: tMitarbeiter: Nachname, Abteilung, Gehalt tAbteilung: Abteilung, Raumnummer Die 'Abteilung' muß in beiden Tabellen erfaßt werden, da nur so eine Beziehung zwischen den beiden Tabellen heregestellt werden kann. Wichtig z.B. bei der Frage: "Arbeitet Abel in Raum 123?" Jetzt sucht man in der Tabelle 'tMitarbeiter' Abel heraus, erfährt so die Abteilung, in der sie/er arbeitet und kann anschließend in der Tabelle 'tAbteilubg' die Raumnummer ablesen. Umgekehrt könnte man fragen, wer denn in Raum 234 arbeitet. Jetzt wird in 'tAbteilung' nachgeschaut, welche Abteilungen in Raum 234 sitzen (Und es können ja in unserem Datenbankmodelldurchaus auch mehrere Abteilungen in einem Raum untergebracht sein! (Wie man so etwas verhindern kann: Dazu später)). Ich nehme einmal an, in Raum 234 befindet sich der Schreibpool und die Poststelle. Nun wird die Tabelle 'tMitarbeiter' durchsucht und alle Mitarbeiter, die in den beiden Abteilungen arbeiten, werden ausgegeben. Ein weiterer Vorteil: Alle Abteilungen mit ihrer momentanen Raumnummer werden nur noch genau einmal in 'tAbteilung' erfaßt. Ändert sich für eine Abteilung die Raumnummer, ist jetzt nur noch genau eine Änderung der Raumnummer in 'tAbteilung' nötig! Und noch ein Vorteil: Für jeden Mitarbeiter wird nur noch die Abteilung in 'tMitarbeiter' erfaßt; die Raumnummer ist ja aus der Tabelle 'tAbteilung' hinterlegt. Tip: Bei Verständnisschwirigkeiten bietet es sich an, nachzufragen, ob ich mich nicht verständlicher ausdrücken kann oder man nimmt sich Karteikärtchen und simuliert mal ein paar Abteilungs- bzw. Raumwechsel. Grüße und viel Spaß weiterhin piomode1 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 21. Oktober 2001 Autor Teilen Geschrieben 21. Oktober 2001 Keinerlei Verständnisschwierigkeiten bisher! :-) Ich freue mich, hier Hilfe gefunden zu haben! Vielleicht kommen noch Anwendungsbeispiele und die Vorteile und Nachteile einiger Datenbankanwendungen (Wie Access oder so)? Wäre schön! Danke StMi Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 30. Oktober 2001 Teilen Geschrieben 30. Oktober 2001 Hi, SteffiMichi! Vor- und Nachteile kann ich schlecht auflisten, da ich bisher nur unter Access 2.0/97/2000 Datenbanken entwickelt habe. Und daß es bei MS Mängel gibt - dazu gibt es a.a.O. genügend Schriftverkehr... Also: Alles was ich hier so vin mir gebe ist relativ eng an Access geknüpft. Betrachten wir heute also mal so zwischendurch eine Sache, die jedem DB-Entwickler immer wieder über den Weg läuft: Die referentielle Integrität [rI]. Nehmen wir nochmal das Abteilungsbeispiel, in dem noch keine Beziehungen definiert wurden. Es ist in diesem Moment durchaus möglich, einem Mitarbeiter eine Abteilung zuzuweisen, die (noch) gar nicht existiert. Mal eben zwischendurch: (Im folgenden lege ich hier einmal folgende Formatierung fest: Tabellennamen Primärschlüssel tMitarbeiter: Nachname, Abteilung, Gehalt tAbteilung: Abteilung, Raumnummer An dieser Stelle ist es zweckmäßig, eine Beziehung zwischen den beiden Tabellen aufzubauen. ***** Allgemein: Es gibt drei Beziehungsarten. 1) 1:n Dieses ist wohl die am meisten erstellte Beziehung. In diesem Bsp. gibt es zu 1 Abteilung n Mitarbeiter. Die Interpretation 1 Mitarbeiter ist in n Abteilungen tätig ist hier falsch (unmöglich), da die 'Abteilung' in 'tAbteilung' der Primärschlüssel ist, und der ist (von Natur aus) 1deutig. (Fragen zum Primärschlüssel?) D.h. also, daß in der Tabelle 'tAbteilung' jede Abteilung nur einmal erfaßt wird, sie in der Tabelle 'tMitarbeiter' (natürlich) öfter (n-mal) auftauchen kann. (Dort ist das Feld 'Abteilung' ja kein Primärschlüssel.) Nebenbei bemerkt: Genau ein Feld ist Primärschlüssel. Daraus ergibt sich dann, welche Tabelle die 1-Seite darstellt. Dann gibt es noch 2) die 1:1 Beziehung Diese Beziehung macht im ersten Augenblick keinen Sinn: Einem Datensatz [DS] der einen Tabelle ist genau ein DS der anderen Tabelle zugeordnet. Dann kann man doch alle Datenfelder in einer Tabelle gemeinsam verwalten. Ja, richtig. Es macht aber irgendwann doch Sinn. Mehr dazu (viel) später. Nebenbei bemerkt: Bei dieser Beziehungsart sind beide verknüpften Felder Primärschlüssel. und 3) die undefinierte Verknüpfung Diese Beziehung liegt vor, wenn keines der beiden verknüpften Felder Primärschlüssel ist. Ganz selten benutzt und in den meisten Fällen resultierend aus einem Fehler in der Tabellenstruktur. ***** Wenn also eine Beziehung aufgebaut wurde und keine weiteren Optionen gewählt wurden, ist es nach wie vor möglich, Mitarbeitern Abteilungen zuzuweisen, die (noch) nicht existieren! Um das zu verhindern, verändert man die Beziehung derart, daß man rI fordert. Dann ist es so, daß nur noch in der Tabelle 'tAbteilung' (also auf der 1-Seite) existierende Abteilungen den Mitarbeitern in der Tabelle 'tMitarbeiter' (also auf der n-Seite) zugewiesen werden können. Nun kommt die berechtigte Frage:"Wer hat denn alle Abteilungen im Kopf?" Berechtigt. Die Lösung liegt in der Nachschlagefunktion, ist aber (wahrscheinlich) accessspezifisch, so daß ich an dieser Stelle nicht weiter darauf eingehe. (Später mehr dazu...) So, jetzt können wir also beruhigt den Mitarbeitern Abteilungen zuweisen. Wollen wir eine nicht in 'tAbteilung' erfaßte Abteilung in 'tMitarbeiter' eingeben, erscheint eine Fehlermeldung (, die mehr oder weniger gut verständlich ist). Jetzt haben wir aber ein bis zwei neue Probleme: 1) Wenn wir eine Abteilung aus 'tAbteilung' löschen wollen, und wir haben diese Abteilung mindestens einem Mitarbeiter zugewiesen, erscheint wiederum eine Fehlermeldung. Es würden dann Datensätze [DSe] in 'tMitarbeiter' Abteilungen beinhalten, die dann nicht mehr existieren würden! Lösung: In der Beziehung wird die 'Löschweitergabe an Detaildatenfeld' vereinbart. Wenn nun DSe auf der 1-Seite gelöscht werden, schaut Access nach, ob referierende DSe auf der n-Seite existieren. Wenn ja, werden diese ebenfalls gelöscht. Problem dann hier: Wird eine Abteilung gelöscht, werden alle Mitarbeiter dieser Abteilung ebenfalls gelöscht!! 2) Wenn sich eine Abteilungsbezeichnung ändert, und wir haben diese Abteilung mindestens einem Mitarbeiter zugewiesen, erscheint wiederum eine Fehlermeldung. Es würden dann Datensätze [DSe] in 'tMitarbeiter' Abteilungen beinhalten, die dann nicht mehr unter der alten Bezeichnung existieren würden! Lösung: In der Beziehung wird die 'Aktualisierungsweitergabe an Detaildatenfeld' vereinbart. Wenn nun Abteilungen auf der 1-Seite umbenannt werden, schaut Access nach, ob referierende DSe auf der n-Seite existieren. Wenn ja, werden diese Abteilungene benfalls umbenannt. Soviel für heute... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 5. November 2001 Autor Teilen Geschrieben 5. November 2001 In der grauen Realität sieht immer alles anders aus...! Soeben sind wir am durcharbeiten einer englischen Interbasetutorial! Wir verstehn aber so gut wie nix! :mad: Also auf Deutsch: Wir brauchen dringend Hilfe! Es handelt sichn um Interbase 5.0 MfG StMi :confused: :eek: :mad: Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 23. November 2001 Teilen Geschrieben 23. November 2001 Hallo, endlich wieder... Interbase 5.0 sagt mir überhaupt nichts! Wie schon geschrieben: Ich bin ein Access-Programmierer (mit Scheuklappen(?))! Ich hoffe, alle 'hilsbedürftigen' Interbaseler haben u.U. a.a.O. bereits Hilfe erhalten!! Ich war ja nun lange im Forum. Sollte trotzalledem weiterhin Bedarf an der Fortführung dieses 'Lehrgangs' bestehen, laßt es mich wissen. Ich werde dann versuchen den Faden wieder aufzunehmen und mich bemühen, die Beschreibungen so allgemein wie möglich zu halten. Bis dann Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 23. November 2001 Autor Teilen Geschrieben 23. November 2001 Danke! Nein die Fortführung ist zumindest für mich nicht mehr nötig! Interbase 5.0 ist halt so ein Programm, wo man die Datenbanken im SQL-Befehl erstellt. Also mit CREATE DATABASE / CREATE TABLE / INSERT INTO / SELECT FROM usw. Letztlich habe ich mich auch mit Access befasst und gemerkt, dass es da ja eine SQL-Ansicht gibt. Also, wenn ich eine Datenbank in Access erzeuge/modifiziere schreibt der mir den SQL-Code mit! Aber, wenn du Interbase kennst, verstehst du zwar Access und findest es tierisch einfach, aber die Art, in der Access seinen Code formuliert ist dermaßen umständlich! Da befinden sich z.B. unnötige Klammern und so Zeug drin! Jedenfalls bin ich froh, dass man Interbase DBs über die ODBC - Schnittstelle in Access importieren kann! Gruß StMI LIFE DATABESES FOREVER! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
hades Geschrieben 24. November 2001 Teilen Geschrieben 24. November 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von piomode1: <STRONG> Genau ein Feld ist Primärschlüssel. </STRONG> Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 29. November 2001 Teilen Geschrieben 29. November 2001 Hi, hades! SUPER! Mit Deinem Einwand, der Primärschlüssel kann auch aus mehreren Feldern bestehen, hast Du natürlich Recht. Ich habe an zitierter Stelle evtl. nicht deutlich darauf hingewiesen, daß es nur in diesem Beispiel so ist, daß der Primärschlüssel aus nur einem Feld besteht! Und sehr schön übersichtlich ist auch Deine Auflistung der x:y-Beziehungen. Noch ein Wort zu der undefinierten Verknüpfung: Access stuft (wie bereits geschrieben) eine Verknüpfung derart ein, wenn keines der beiden miteinander verknüpften Felder eindeutig ist. <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR> Original erstellt von hades Wie kennzeichnest Du folgende Datensätze der Tabelle tMitarbeiter mit minimalen Mitteln eindeutig? Meier, Entwicklung, 5000 Mueller, Entwicklung, 4500 Meier, Entwicklung, 5500 Schulz, Entwicklung, 3000 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
hades Geschrieben 30. November 2001 Teilen Geschrieben 30. November 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von piomode1: <STRONG>Minimaler Aufwand: ein Feld mit AutoWert. Relativer Aufwand: ein (ohne Duplikate indiziertes) Feld, in das ich eine KundenNummer eingebe. </STRONG> Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
piomode1 Geschrieben 7. Dezember 2001 Teilen Geschrieben 7. Dezember 2001 Hi, hades! Ich bin Access-Spezi. Andere Datenbanksysteme sagen mir (leider(!)) nicht viel . Ebenso die Portierbarkeit. Daher meine obigen 'Entscheidungen'. ----- Hi, SteffiMichi! Z.Zt. leider keine Zeit vorhanden, viel weiteres zu schreiben. Evtl. nächstes Jahr...!? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SteffiMichi Geschrieben 7. Dezember 2001 Autor Teilen Geschrieben 7. Dezember 2001 Ach nee muss net sein @piomode1 Habe mich jetzt mit Datenbanken ganz gut geschlagen! Aber wenn ich mal wieder Hilfe brauche wende ich mich vertrauensvoll an dich! Wir haben halt mit Interbase (interaktive SQL-Befehle) und dann noch mit Access gearbeitet und ich komm ganz gut damit klar! Jetzt ist erst wieder ein Block Schule und Datenbanken brauch ich im Moment nicht! Ciao und danke nochmal! StMi Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.