VisualBasic Access DB Normalisierung

Sorry, deine Antwort zeigt einfach, dass Du das Thema Datenmodellierung und Normalisierung nicht ganz verstanden hast oder es einfach nicht einsiehst.
Ein Ziel der 3NF ist die transitive Abhängigkeit. Es geht nicht darum, sie zu vermeiden, sondern darum sie zwischen den Entitäten herzustellen, da genau darin die Stärken einer relationalen Datenbank liegen. Ansonsten kann man seine Datenhaltung auch in einem Flatfile vornehmen und spart sich den ganzen Zirkus. Teilweise ist das sogar performanter. Es gibt da ganz spezielle Anwendungsfälle, bei denen man das mit Absicht so macht. Dieser hier gehört aber nicht dazu.

In der Anwendung selber definiert man keine "Terminarten", die man dann in der Datenbank verwendet um Termine zu kategorisieren. Das verstößt gegen alle sinnvollen Entwurfsmuster ordentlicher Softwareentwicklung, gegen allgemeine Regeln der Datenmodellierung und gegen gutem Geschmack. Es ist einfach von vorne bis hinten falsch es so umzusetzen. Da kann man auch nichts dran schönreden. Auch nicht, indem man sagt "das ist doch nur eine kleine Access Anwendung". Als ob man solche Anwendungen nicht auch richtig erstellen dürfte? Gammelt einem dadurch die Hand ab? Es ist nicht mal komplizierter bei der Abfrage der Daten. Einfach ein "View" (Access: Abfrage) drum herum kloppen und fertig ist die Laube. Zuzüglich der Dinge, dass es einfacher bzw. überhaupt erst möglich ist so Pattern wie MVC einzuhalten usw.

Potenziell fehleranfällig (und ein Verstoß gegen bewährte Entwurfsmuster wie MVC) ist es Daten, die in einer Datenbank eingetragen werden sollen irgendwo fest in die Software zu codieren. Abgesehen davon, dass das Ergänzen von Terminarten auf diese Art nervt wie sau haut man sich auch schnell mal die Feldgrößen der Datenbank selbst um die Ohren.
Das hat auch nichts mit unterschiedlichen Sichtweisen als DB-Entwickler oder Softwareentwickler zu tun. So etwas habe ich in meinem Berufsleben ernsthaft noch nie gehört. Also, dass sich da die Sichtweisen voneinander unterscheiden würden. Ein Softwareentwickler arbeitet ständig mit den Entwurf von Datenbanken, da kommt man gar nicht drum herum. Nur kann man das halt aus (falscher) Überzeugung falsch oder einfach richtig machen. Ersteres ist nicht unbedingt ein Qualitätsmerkmal...

ayngush,
bitte verallgemeiner nicht: Es ist durchaus gelegentlich sinnvoll Typen in einer Datenbank festzucodieren - und zwar ohne Tradeoff.

​Ich sehe darüber hinaus nicht, inwiefern eine solche Vorgehensweise mit MVC in Konflikt steht: MVC ist ein Architekturmodell der auf der Datenbank basierenden Software, in welcher das Model die Datenbank wegabstrahiert. Das heißt weder die View noch der Controller haben kennen Implementierungsdetails der Datenbank. Wo ist nun das Problem, wenn im Model Werte festcodiert werden?

Ein Softwareentwickler arbeitet ständig mit den Entwurf von Datenbanken​

Zum Vergrößern anklicken....

Viele Softwareentwickler

​Darf ich fragen wieviele Jahre du schon als Softwareentwickler arbeitest und vor allem mit welchen Typ von Anwendungen?

Es ist in dem Fall einfach nicht sinnvoll. Ich habe bisher auch kein einziges Argument gelesen, welches belegen würde, dass es sinnvoll ist die TerminArten jedes mal als String (Egal ob aus einer Werteliste oder Freitexteingabe) in die Termin-Tabelle einzutragen. Die Terminarten, wie sie hier im Thread beschrieben sind, sind ganz eindeutig eine eigene Entität und es gibt dafür nur einen sinnvollen und richtigen weg, diese in die Datenbank zu schreiben.
Einfach eine TerminArten-Tabelle anlegen, den Fremdschlüssel in die Termin-Tabelle eintragen und schon ist alles OK.

Bezogen auf die Access-Anwendung wäre eine statisch codierte Werteliste, egal ob die Access-DB nur als reiner Datentank für die äußerliche VB-Anwendung dient oder nicht, nicht im Model, sondern im View oder im Controller - aber das weißt Du sicherlich selber. Auf die Möglichkeit, dass es Sonderfälle gibt, bei denen so ein Vorgehen, wie von Dir beschrieben, sinnvoll ist habe ich auch schon bereits mehrfach hingewiesen - so ein Fall liegt hier aber konkret einfach nicht vor.

Ich habe knapp zwölf Jahre Berufserfahrung als Entwickler (erst Junior, jetzt Senior + PL) mit genau solchen Anwendungen: CRM-Systemen in der Finanz- und Versicherungsbranche. Aber auch mit den Schnittstellen, die da so notwendig sind und werden (GDV-VU-VM / BiPRO / TGIC-Webservices) und weiteren Dingen wie DMS-System-Einbindungen usw.
Und was machst Du so?
Es ist im Business dann einfach kein Spaß mehr, wenn man nicht durchdachte Datenmodelle vor der Nase hat. Und ja, meine Erfahrung zeigt leider, dass das eher die Regel, denn die Ausnahme ist. Ich weiß auch nicht, ob das zu kompliziert ist oder warum sich so viele Leute damit so schwer tun. Es ist ein beschriebenes Regelwerk, es folgt einer Logik, man kann es sauber abbilden, wo ist das Problem? (für einen IT-ler)