Prüfung ziemlich leicht

[Danarama]

Original geschrieben von laurel

Hallo!

@Danarama Du hast vergessen, dass die Mitglieder mehrere Anschriften und Telefonnummern sowie email-Adressen haben. Das macht nochmal 3 Tabellen :-)

Hab ich nicht vergessen. Bin davon ausgeganfen, dass Adresse/Telefon eindeutig --> in Mitgliedertabelle, das von Schlüssel direkt abhängige Attribute (3. Normalform).

Mitgliedertabelle:

M_ID

Name

Vorname

Strasse1

PLZ1

Ort1

Strasse2

PLZ2

Ort2

Tel_firma

Tel_home

mail

etc. pp.

Müsste Boyce-Codd-konform sein.

[Danarama]

Original geschrieben von laurel

Das sind doch Mehrfachgruppen und die sind nach der ersten NF auszugliedern!!!

Und wenn ich für alle member drei bis vier mögliche Felder für Telefonnummern oder die Felder für zwei Adressen habe, gibt es doch eine Menge verschenkten Speicherplatz, wenn der member weniger angibt(oder angeben will).

Du hast da was falsch verstanden...

Laut erster Normalform müssen die Werte atomar sein, d.h. Du darfst _nicht_ die Strasse, die PLZ und den Ort zusammenstecken. Das hat jetzt noch gar nichts mit den Tabellen zu tun, sondern nur mit der Aufteilung der Werte innerhalb einer Tabelle.

Gruß,

Dana

[laurel]

Original geschrieben von Danarama

Du hast da was falsch verstanden...

Laut erster Normalform müssen die Werte atomar sein, d.h. Du darfst _nicht_ die Strasse, die PLZ und den Ort zusammenstecken. Das hat jetzt noch gar nichts mit den Tabellen zu tun, sondern nur mit der Aufteilung der Werte innerhalb einer Tabelle.

Strasse, PLZ und Ort sind Attribute.

Wenn jetzt ein Attribut in einer Entity mehrfach vorkommt, ist es eine Mehrfachgruppe. Bei der Normalisierung bis zur dritten NF werden diese dann in eigene Entities ausgegliedert.

Gruß laurel

[Zaknafein]

Original geschrieben von pherweg

Auch auf die Gefahr hin, mich unbeliebt zu machen:

So wollte ich auch grade einen Thread anfangen...

Ich wuerde sie nicht "leicht" nennen - aber machbar - gut machbar.

Ich kann natuerlich nur FISI beurteilen, aber GA2 und WISO sollen ja auffallende Aehnlickeiten bei beiden aufweise ;o)...

BAB stand - wie schon oft erwaehnt - im Buch, SQL waren simple Aufgaben (bis auf das UPDATE-Teil vielleicht, aber selbst mit Online-Hilfe-Kenntnissen ueber SQL haette man die anderen loesen muessen, ein INNER JOIN is nu echt nich die Welt)...

okay, haesslich war VoIP (aber da war die Haelfte der Punkte mit der einfachen Auflistung aller benoetigten Komponenten einzufahren, mit ein bisserl Phantasie oder vielleicht CounterStrike auf dem heimischen Rechner kann man sich da endlos was aus den Rippen schneiden) und VLAN - aber nur die wirklich guten sollten mit ner 1 dort rausmarschieren, also haben die weniger perfekten die VLAN-Aufgabe eben nicht geloest.

WISO war bitter, einige fiese Fragen imho - aber auch viele sehr einfache, teilweise Wiederholungen aus anderen Pruefungen (man denke nur an den Laser) - 50% sollten drin sein. Mit der schwachen Gewichtung zieht das nicht mal die Note runter.

Was war noch? Ach ja, die Zeit... Das versteh ich echt nicht...

Als die Tante da was von "noch 30 Minuten" erwaehnte (GA2) war ich bereits mit SQL beschaeftigt - habe BAB verdraengt. Nach SQL (max. fuenf Minuten!!) hatte ich noch 25 Minuten Zeit, die Zahlen aus der Pruefung mit denen im Buch zu vergleichen und die Rechnungen nachzuvollziehen - und Nein, weder hatte ich BAB je in der BS noch habe ich im Betrieb davon gehoert noch mich privat damit beschaeftigt...

Bei GA1 habe ich die letzten 20 Minuten nach Fehlern in meinen Loesungen gesucht - gebe allerdings zu, dass ich einiges nur zaghaft angefasst habe, und auch einiges an Fehlern schon weiss - aber zeit war nicht mein Problem...

[Ricoh]

Wollt nur ma erwähnen das BAB in meinem Tab-Buch NICHT drinn stand.

SQL hab ich nur die SELECT Befehle hingekriegt. (Sowas wie Summieren oder UPDATE weiss ich nunma nicht auswendig / ist doch eher was für Anwendungsentwickler)

Bei VoIP konnte man sich wohl ein paar Komponenten zusammenreimen.

Bei VLAN hab ich überhaupt nix. (Die Frage ist meiner Meinung nach wirklich n Hammer / in der Schule hab ich davon nix gehört)

Ricoh

[Danarama]

Original geschrieben von laurel

Strasse, PLZ und Ort sind Attribute.

Wenn jetzt ein Attribut in einer Entity mehrfach vorkommt, ist es eine Mehrfachgruppe. Bei der Normalisierung bis zur dritten NF werden diese dann in eigene Entities ausgegliedert.

Gruß laurel

Nochmal zum mitmeißeln:

1. Normalform: Eine Relation befindet sich in der ersten Normalform, wenn keines ihrer Attribute eine untergeordnete Relation darstellt und wenn alle Attribute nur atomare Werte beinhalten.

2. Normalform: Laut Definition muß die Datenbank immer zuerst in die erste Normalform versetzt werden, bevor man diese in die 2. Normalform versetzen kann. Hierbei müssen alle nicht zum Schlüssel gehörenden Attribute von diesem voll funktional abhängig sein. Besteht ein Schlüssel aus mehreren Teilschlüsseln, so ist das Element aus dem Datensatz herauszuziehen, welches nur von einem Teilschlüssel abhängt.

3. Normalform: Zusätzlich zur 2. Normalform gilt für jeden Schlüssel: Alle nicht zum Schlüssel gehörende Attribute sind nicht von diesem transitiv abhängig. Das bedeutet, daß alle Attribute nur vom Schlüsselattribut, nicht aber von anderen Attributen abhängig sein. Eine Abhängigkeit zwischen den Attributen muß aufgelöst werden.

4. Normalform: Diese 4. Normalform betrifft Mehrfachabhängigkeiten von Attributmengen von einem Superschlüssel (Übergeordneten Schlüssel). Diese muß in Einzelabhängigkeiten (Siehe 3. NF) aufgelöst werden.

5. Normalform: Falls in der 4. Normalform keine verlustlose Zerlegung in Einzelabhängigkeiten möglich ist, dann muß eventuell 2., 3. ... Superschlüssel hinzugezogen werden, solange, bis nur noch Einzelabhängigkeiten der Attribute von einem oder mehreren Superschlüsseln bestehen.

So, also was wolltest du nochmal sagen?

Nochmals am Bsp. 2 Postleitzahlen:

PLZ1 ist doch nicht von PLZ2 abhängig. Genausowenig ist PLZ1 gleich einer PLZ2. Hierbei besteht überhaupt keine Abhängigkeit zwischen PLZ1 und PLZ2.

Es sind 2 grundverschiedene Attribute, welche beide gleichermassen vom Primärschlüssel (hier Mitglied_ID) abhängig sind.

Da angegeben war, dass genau 2 Adressen benötigt waren (nicht mehr und nicht weniger) brauchst du IMHO keine Extratabelle.

Gruß,

Danarama

Bitte poste doch mal deinen DB-Entwurf. Danke

[laurel]

wovon hängt denn alles der Ort ab?

oder die Strasse?

die sind doch nicht nur von der M_ID abhängig?

Ort und PLZ stehen gegenseitigt in einer n:m-Beziehung

und die Strasse kann bei mehreren Leuten auftreten

mehr sage ich nicht mehr, das Resultat erfahren wir in 3 bis 4 Wochen (da sind wir uns doch einig;) ).

Gruß laurel

[Danarama]

Original geschrieben von laurel

wovon hängt denn alles der Ort ab?

oder die Strasse?

die sind doch nicht nur von der M_ID abhängig?

Ort und PLZ stehen gegenseitigt in einer n:m-Beziehung

und die Strasse kann bei mehreren Leuten auftreten

mehr sage ich nicht mehr, das Resultat erfahren wir in 3 bis 4 Wochen (da sind wir uns doch einig;) ).

Gruß laurel

Ähem, soweit ich weiß wäre eine solche Auflösung korrekt, aber nach 4. Normalform... und die war (glücklicherweise) nicht verlangt...

--> Da wir uns schon nicht einig sind, was wollen die von der IHK dann als richtig bewerten? Wahrscheinlich is alles richtig, was mehr als 3 Tabellen darstellt... Kurse, Mitarbeiter,

Eignung...

[laurel]

sorry hier noch meine Entities:

Mitglieder

Anschrift (n:1 Mitgl)

Telefon/Fax (n:1 Mitgl)

Messung (n:1 Mitgl)

EMail (n:1 Mitgl)

Kurs

Anforderung/Fitness (1:n Kurs)

Kursangebot (n:1 Kurs)

Buchungen (n:1 Kursangebot; n:1 Mitgl)

So hab ich es niedergeschrieben.

Gruß laurel

[teradux]

Original geschrieben von laurel

wovon hängt denn alles der Ort ab?

oder die Strasse?

die sind doch nicht nur von der M_ID abhängig?

Ort und PLZ stehen gegenseitigt in einer n:m-Beziehung

und die Strasse kann bei mehreren Leuten auftreten

mehr sage ich nicht mehr, das Resultat erfahren wir in 3 bis 4 Wochen (da sind wir uns doch einig;) ).

Gruß laurel

Deswegen habe ich auch eine Orte-Tabelle erstellt.

Einem Ort ist eine PLZ zugeordnet. und da es doch PLZs gibt die es für zwei verschiedene Orte gibt, hab ich noch ne OrtID dazugetan.

Aber Strasse1, Tel1, Fax1, OrtID1 und Strasse2, Tel2, Fax2, OrtID2 sind nur vom Mitgliedsschlüssel abhängig.

Zuerst habe ich Dir Aufgabe auch so verstanden, dass beliebig viele Adressen eingegeben werden können. Doch dann bin ich zum Schluß gekommen das Sie in der Mehrzahl geredet haben weil Sie die private und die geschäftliche Adresse meinten.

Also sind es nur zwei und das passt dann....

[Lachdanan]

Für Fax/Telefon braucht man auch noch 2 Tabellen:)

zum einen:

Tel_Kategorie

TelKat_ID (PK)

Bezeichnung

sowie die eigentliche:

Telefontabelle

Tel_ID (PK) (muss eventuell nicht vorhanden sein)

TelKat_ID (FK)

Mitglieds_ID (FK)

TelNr

[teradux]

Original geschrieben von Hunchback

Für Fax/Telefon braucht man auch noch 2 Tabellen:)

Des versteh ich nicht.

Es waren jeweils 2 Fax- und Telefonnummern.

Und da diese Angaben nur von der M_ID abhängig sind barch ich doch da keine Kategorien und dann noch die Werte....!?

Naja, in ca nem Monat werden wirs wissen..... *hoffe*

[Lachdanan]

Ein Mitglied hat aber in der Regel doch nur ein Attribut

names Telefon, auch wenn er noch so viele Nummern hat.

Also kann man doch nicht einfach 2 Attribute mit dem

Namen Telefon in die Mitgliedertabelle haun'. Was ist mit den

Leuten die <2 Telefonnummern haben? Bleibt bei denen dann

die Spalte 'Tel'2 leer? Lieber die Mitgliedsnummer als FK in die

Telefontabelle und in der Mitgliedertabelle nix von Tel rein. Es

kann ja sein, dass es ein bisschen umfangreicher ist, aber so

ist es auch mal leichter erweiterbar.

[s_koenig]

Original geschrieben von thomee

[ich bin ein guter Schüler und hab gewiß mehr in Richtung Netzwerk gemacht als ein Groß der restlichen FISIs. Was da über Voice over IP und Vlan gefragt wurde hatte ich nie in der Schule und erst recht nicht im Betrieb. Das war ein Witz!

Ansonsten war die Prüfung ok. Zeit war jedoch nicht angemessen.

cu,

Thomas

Hallo Thomas und alle anderen ....

da kann ich Dir leider nur recht geben. Ich bin ca. 15 Jahre als EDV-Leiter tätig (Mittelständische Betriebe mit ca. 100 - 200 PC-Arbeitsplätzen) und habe jetzt berufbegleitend diese Ausbildung zum FiSi gemacht ... (ich frage mich immer noch wozu :-) )

In habe immer mal wieder was von VLAN oder Voice over IP gehört, aber bisher keinen getroffen, der sich damit wirklich auskennt ....

Und dann dieser BAB, bäh

Gruß

Stefan :eek:

[StarLord]

Original geschrieben von Franchy

Deswegen habe ich auch eine Orte-Tabelle erstellt.

Einem Ort ist eine PLZ zugeordnet. und da es doch PLZs gibt die es für zwei verschiedene Orte gibt, hab ich noch ne OrtID dazugetan.

Aber Strasse1, Tel1, Fax1, OrtID1 und Strasse2, Tel2, Fax2, OrtID2 sind nur vom Mitgliedsschlüssel abhängig.

Logisch ist dein Vorschlag schon, aber der Aufwand ist einfach zu groß. "PLZ1, Ort1 und PLZ2, Ort2" hätten auch gereicht. Man merkt womit ihr euere wertvolle Prüfungszeit verplempert...

Gruß,

DarkSoul

[teradux]

Original geschrieben von StarLord

Logisch ist dein Vorschlag schon, aber der Aufwand ist einfach zu groß. "PLZ1, Ort1 und PLZ2, Ort2" hätten auch gereicht. Man merkt womit ihr euere wertvolle Prüfungszeit verplempert...

Gruß,

DarkSoul

Vielleicht hast Du recht, aber da kommt halt der Entwickler in mir...

Original geschrieben von Hunchback

Ein Mitglied hat aber in der Regel doch nur ein Attribut

names Telefon, auch wenn er noch so viele Nummern hat.

Also kann man doch nicht einfach 2 Attribute mit dem

Namen Telefon in die Mitgliedertabelle haun'. Was ist mit den

Leuten die <2 Telefonnummern haben? Bleibt bei denen dann

die Spalte 'Tel'2 leer? Lieber die Mitgliedsnummer als FK in die

Telefontabelle und in der Mitgliedertabelle nix von Tel rein. Es

kann ja sein, dass es ein bisschen umfangreicher ist, aber so

ist es auch mal leichter erweiterbar.

Doch man kann - wie Du siehst.

Ne Scherz ohne. Sicher hast Du recht, wenn wirklich mehrere Adressen aufgenommen werden sollen, dann ok aber es ging nur um privat und geschäftlich.

Und die beschriebene Situation kommt häufig in der Praxis vor. Daher weiß ich das daraus keine extra Tabelle gemacht wird.

Außerdem entspricht es gegen die 1,2 und 3 Normalform. Es muß also net ausgegleidert werden. Bei der 4ten hab ich keine Ahnung, vielleicht da!?

Außerdem hat diese Art von Erweiterbarkeit einen ziemlichen performance Nachteil. So ein JOIN in ner Abfrage macht die SELECT Anweisung auch net grad schneller......

Aber wie schon gesagt. Die Korrektuere sind ja keine Unmenschen und normalerweise haben die Fachwissen und ich denke die können sich in die Situation schon eindenken. Ganz so blöd sind die schon net. *hoffe*

[Karloenzo]

Hallo FiSi'en,

Im großen und ganzen fand ich die Prüfung nicht sooo übel.

Ich sage das obwohl ich weiß das ich mindestens die GH1 vollkommen versiebt habe und mit "better luck next Time" rechne. Deshalb genügte mir auch die Zeit denn als ich alles hingeschrieben hatte was ich wußte waren noch 45 Minuten übrig.

Ich bin auch schon seit C64 Zeiten mit Prozessoren und Betriebssystemen auf du und du. Ich muß leider feststellen das ich (wenn ich mir meine Prüfung anschaue) von EDV keine Ahnung habe.

Das Berufsbild des FiSi ist einfach zu umfangreich.

Ich werde mit Sicherheit nie in Verlegenheit kommen BAB, SQL-Anweisungen, VLAN-Swtichkonfis in meinem Job aus dem Stehgreif zu benötigen.

Auch VoiceoIP oder VLan ist mir noch nicht untergekommen. Geschweige denn das ich mich hätte jemals mit dem aufmahlen der Verkabelung hätte rumschlagen müssen.

Ich frage mich wieso nicht ein bisserl das Thema Internet in der Prüfung drankam (Firewall, Datensicherheit und und und). Aber das ist wahrscheinlich bei der ZPA seit der letzten Prüfung abgehakt und für alt befunden worden :-).

Gruß Kalle

(nehme mir heut einen Strick und erschieß mich :-)

:(