Access Datenbank

Heidiho Freunde der Prgrammiersprache
Ich möchte für das Antiquariat in dem ich gerade tätig bin eine Datenbank mit Access machen. Wir haben ein Barsortiement von ca. 60.000 Büchern, und da den Überblick zu behalten ist wirklich schwierig. Daher hab ich mir gedacht der Besitzterin eine Bücherdatenbank zu machen. So das man dann halt alle Bücher in der Datenbank aufnimmt, mit Titel, Autor, Preis, Anzahl und vielleicht noch Verlag und ISBN-Nummer. So das man dann nachher nur noch eine der Informationen in eine Suchmaske eingibt und dann das Buch, oder halt alle Bücher eines Autors angezeigt bekommt.
Ich weiß das man sowas mit Access machen kann, das hatten wir mal in der Schule kurz angeschnitten. Aber leider sind wir nicht tief genug gegangen. Ich weiß halt nur das es wohl damit geht, aber nicht wie.
Kann mir hier jemand weiterhelfen?
Sprich: Mir ne Art Anleitung schreiben, für gan ganz blöde. Oder auf ne Anleitung verlinken?

Danke

anleitung wirst du im netz finden. im grunde gehts erstmal darum die daten irgendwie in tabellen zu bekommen. da fängts dann auch schon an, du kannst nicht alle daten in eine tabelle schreiben, das geht nicht und ist auch noch unvorteilhaft.

google dir also mal nach "normalisierungsregeln", das sind die regeln anhand derer du dein datenbankschema entwerfen wirst. das ist dann das nächste du musst erstmal ein schema entwerfen also quasi am besten auf papier mal aufmalen welche einzelnen tabellen du haben willst, was da drinstehen soll und wie sie verknüpft sind. das nennt man ER.

google also nach entity relationship model.

wenn der ganze summs dann irgendwann digital vorliegt dann gehts daran ne oberfläche für die benutzer draufzubügeln. das machst du mit "formularen", das ist etwas accessspezifisches und hierfür findest du wirklich sehr viel im internet... gerade für deinen standardfall. allerdings wirst du das eine oder andere mal mit visual basic code und/oder sql-queries konfrontiert werden... den gilts zumindest oberflächlich zu verstehen.

wenn dir das alles zu blöd ist dann verwende die assisstenten von access. zu nem ein oder anderen ergenis kommst du damit auch aber ich bezweifle dass es ne benutzbare anwendung werden wird.

besser hätte mans nicht ausdrücken können

und wenns dir zu schwer so ist dann lass dir gesagt sein das bei 60000 Zeilen in einer datenbank (und dazu kommen noch x spalten macht also 6000*x felder) hast du bei ner nicht normalisierten rotzdb irgendwann einen sudden death wie du ihn dir nicht wünschen solltest

also: lesen, lesen, lesen. aber schwer ist das nicht zu verstehen. kannst ja hier nachfragen wenn du was nicht verstehst.

okay, wenn es nur um die speicherung der bücher geht nimm eine tabelle. es wird zwar dann etwas schwerer falls du spezialfälle abdecken willst, aber das solltest du abschätzen. einfach dir fest überlegen was du erreichen willst, und nicht nachher in einen featurewahn verfallen (das wäre noch schon, jenes, und dieses....).

falls du dir dann die tabelle überlegt hast kannst du dir gleichzeitig überlegen ob du es wirklich in access hauen willst oder vielleicht doch lieber php und mysql, bzw. postgresql verwenden willst. beides hat vor und nachteile.

bei der access lösung geht es vielleicht etwas schneller. aber du bist halt auf das system festgelegt.

während du bei einer php und *db lösung das ganze sogar theo. ins internet stellen kannst und es für die meisten etwas leichter zubedienen ist.

wegen der normalisierung:
du hast bestimmte fälle die du mit der normalisierung nur schwer abdecken könntest, z.b. mehrere personen schreiben ein buch. du könntest zwar normalisiert speicherplatz sparen, aber im selben zug verlierst du performance. also tuen sich die beiden lösungen nicht viel, nur du hast mehr arbeit bei der planung und umsetzung.

Bei deiner Problemstellung würde ich dir raten nur eine Tabelle zu verwenden...denn es ist ja noch eine überschaubare anzahl an spalten und es muss meiner Ansicht nach nichts über extrafelder mit einer anderen Tabelle verknüpft werden!

das ist ein unsinniger tipp. selbst wenn er jetzt nur 2-3 tabellen erstellt spart er sich allein dadurch, dass autoren wohl gehäuft identisch vorkommen, enorme arbeit bei der eingabe. ausserdem lernt er dann wie datenbanken arbeiten und funktionieren... "alles in eine tabelle" ist grundlegend eigentlich immer falsch, egal wie wenig daten man hat und tut mir leid aber bei 60.000 datensätzen mit ner moderaten zahl an möglichen feldern sag ich nicht mehr "überschaubare datenmenge"...

Ich sagte ja auch nicht überschaubare anzahl der Datenmenge, sondern der Tabellen spalten...wenn ein Autor natürlich öfters vorkommt, dann lohnt es sich schon eine zweite Tabelle für Autoren anzulegen un diese dann zu verknüpfen...aber da der Themenstarter gesagt hat, dass er absolut kein Plan von Tabellen und Access hat rate ich ihm immer noch zu einer Tabelle...

Also ich find ja immer Beispiele sagen mehr als Worte.

Ich würd 3 Tabellen empfehlen(verlag, autor und buch).

Tab. 'verlag'

vid - ID des Verlags (0-255, autoinc.)
name - Name des Verlags (varchar 255)
...... (Weitere Infos zum Verlag)

Tab. 'autor'

aid - ID des Authors (0-65535, autoinc.)
name - Name des Autors (varchar 255)
...... (Weiter Infos zum Autor)

Tab. 'buch'

bid - ID des Buches (0-16777215, autoinc.)
aid - ID des Autors (0-65535, +INDEX)
vid - ID des Verlages (0-255, +INDEX)
titel - (varchar 255)
isbn - (varchar 255)
preis - (0-65535) (cents)
anzahl - (0-255)

...... (Weitere Infos zum Buch)

Vorteile : übersichtlich, platz sparend und schnell.

der nachteil ist nur was ist wenn mehrere autoren an einem buch gearbeitet haben? normalisiert wäre dies nur durch anlegen von mehr feldern zu erreichen(coautor, 2 coautor, 3 coautor), oder mischeinträge in der tabelle autor(autor + coautor + 2 coautor), beides eher unschön.

sicher zum lernen wäre ein aufbau wie von gagget oder el sparko vorgeschlagen besser, aber es soll ja weniger gelernt werden, er will sie benutzen. dafür muss er nicht unbedingt in die tiefen der datenbank modellierung einsteigen.

die einfachste lösung:

id (halt der schlüssel) (berechnet sich selber)
name des buches (zeichenkette) (suchfeld)
name des/der autoren (zeichenkette) (suchfeld)
verlag (zeichenkette)
genre (zeichenkette) (suchfeld)
isbn (zeichenkette) (suchfeld)
preis (zahl)
anzahl (zahl)
informationen, klappentext (zeichenkette)

das bedeutet ich habe die inhalte:
autoren, verlag, genre doppelt, doch da sich diese nicht ändern werden verliere ich nur speicherplatz, eher zu verschmerzen. gleichzeitig muss er keine verbindungen zwischen den tabelle beachten. auch sind die suchabfragen eher leichter zuformulieren. wenn ich nach einem autor suche, durchsuche ich die komplette tabelle, statt mir erst in der einen die id zuholen und dann in der anderen die bücher raussuchen.

das eine ist halt eine relationalen datenbank, das andere eine objektdatenbank. beides hat vor und nachteile.

http://de.wikipedia.org/wiki/Relationale_Datenbank
http://de.wikipedia.org/wiki/Objekto...atenbankmodell

wenn es mehrere autoren gibt dann ist rein normalisiert eine n:m-relation zu realisieren. kann eine relationelle datenbank nicht, daher nimmt men ne zwischentabelle. das gehört zu den winzigsten grundlagen die ich damals zur datenbankmodellierung gelernt habe.

ich bin immer noch der meinung ein ganz normaler windows anwender, der sich mit access beschäftigen will, wird es hinbekommen 2-3 tabellen zu erstellen und ne linie zwischen denen zu ziehen... sprichwort "beziehungen" in access. das ist wirklich kein hexenwerk.
ich sehe auch nicht wo der "vorteil" sein soll wenn ich zu 50 büchern von "heinz müller" immer wieder "heinz müller" bzw. "h. müller" bzw. "Heinz müller" bzw. "heinz Mueller" etc. eingeben soll... am ende kann ich nichtmal mehr nachverfolgen wieviele bücher ich von dem typ hab. anwender tendieren dazu, oft verschiedene schreibweisen zu verwenden. mit ner extra autorentabelle ist das egal, da hat man den autor ja nur einmal drin.

die eingabe bzw. kontrolle der eingabe ist eine aufgabe der formulare. vorallem ist das problem mit den unterschiedlichen namen auch bei der wahl mit einer extra tabelle gegeben, sprich nachher liegt er in der autorentabelle doppelt oder 100x. aber du hast recht, speicher freundlicher wäre die lösung mit mehreren tabellen, dafür auch aufwendiger.