incertidumbre en el desarrollo de un modelo de base de datos

Estoy tratando de desarrollar un modelo de base de datos para el candidato, sus exámenes registrados y el resultado de los exámenes cuando se toman. Esto es lo que hice hasta ahora. sin embargo, no estoy seguro si estoy en el camino correcto, especialmente desde la mesa de exploración hasta la tabla de resultados del examen. ¿Qué tan fácil será escribir un código insert sql para la población resultante del examen para un candidato en particular?

los tipos de exámenes están categorizados en ciencia, arte y ciencias sociales. todos tienen 4 componentes cada uno

enter image description here

Nota sobre la progresión

Dado el hecho de que la Cuestión cambia sustancialmente (al aclarar el requisito, no el scope) en respuesta a mi Respuesta y TRD, esto va a llevar un poco de ida y vuelta. Identifiquemos los pasos: sus números de pasos son impares, comenzando desde 1; los míos, en respuesta, son pares. Partes de Pasos de respuesta anteriores se han vuelto obsoletas, es posible que ya no tengan sentido.

Sugeriría una recompensa, excepto por el hecho de que tiene pocos puntos.

Paso de respuesta 2 a la pregunta inicial y paso 1 Diagtwig

Esto es lo que hice hasta ahora.

Has hecho un buen trabajo, pero es demasiado pronto para asignar PK. Además, la asignación de una identificación en cada archivo como punto de partida lisiará el proceso de modelado, el resultado no será una base de datos. Primero debe modelar los datos (no la base de datos) y luego asignar claves cuando las entidades son claras y estables. Así que suelte todos sus ID y PK y modele los datos, como datos. Olvídese de lo que quiere hacer con los datos (es decir, olvide la aplicación).

¿Qué tan fácil será escribir un código insert sql para la población resultante del examen para un candidato en particular?

En este momento no puedes. No tiene relación entre el Candidate y el Examination[Result]. Eso no es un problema porque el modelado es incompleto en esta etapa, cuando se complete, el código será simple.

La entidad Course está implícita, pero falta.

sin embargo, no estoy seguro de si estoy en el camino correcto, especialmente desde la mesa de exploración hasta la tabla de resultados del examen

Está en el camino correcto con algunos de los otros archivos, pero el clúster de Examination necesita trabajo. Esto llevará un poco de ida y vuelta. Una vez que responda las preguntas en los comentarios, podemos continuar.

El problema principal es este: cómo se identifica el Examination .

Un campo de ID no identifica nada, ni proporciona exclusividad en los datos , lo cual es necesario si desea integridad de datos. Los identificadores generan un Sistema de archivos de registro sin integridad, sin embargo, parece que desea una base de datos con integridad de datos. Es eso correcto ?

Regrese al usuario y analice cómo se identifican los cursos y componentes, qué códigos usan, etc. Esas son las claves naturales que utilizan para identificar sus datos, que entrarán en el sistema cuando necesiten buscar algo, o ingrese los resultados del examen.

  • P.ej. No es razonable contemplar un Examination que existe de manera independiente (como lo ha modelado). La gente no va a una sala y se sienta para un examen anterior. El examen existe solo en el contexto de un curso, se presentan para un examen de un curso .
  • Luego, el curso, y no el examen, tiene componentes que se examinan. Y cada curso tiene una cantidad diferente de componentes.
  • P.ej. un Course que se identifica como ENG101 para English Literature year 1
  • Y luego los componentes dentro de eso. P.ej. 2b Short essay on poetry.

También es posible que necesiten identificar el año y el semestre del curso, en cuyo caso, necesita un CourseOffering por semestre.

Considere esto, como un punto de discusión. Courier es un ejemplo de datos, el azul es la clave, el verde es la clave:

  • TRD Paso 2

Respuesta Paso 4

Respuesta a la pregunta y descripción

Esto es lo que hice hasta ahora.

Mi respuesta anterior aún se aplica:

Has hecho un buen trabajo, pero es demasiado pronto para asignar PK. Además, la asignación de una identificación en cada archivo como punto de partida lisiará el proceso de modelado, el resultado no será una base de datos. Primero debe modelar los datos (no la base de datos) y luego asignar claves cuando las entidades son claras y estables. Así que suelte todos sus ID y PK y modele los datos, como datos. Olvídese de lo que quiere hacer con los datos (es decir, olvide la aplicación).

No ha abordado ese problema, que identifiqué en su Diagtwig del Paso 1 , en su Diagtwig del Paso 3 . Según las pruebas, parece que puede estar satisfecho con las identificaciones como “Claves primarias” (no las hay), a pesar de que se le haya identificado el obstáculo. Eso significa que su comprensión de los datos está paralizada, y el progreso de sus diagtwigs será lento.

Mi respuesta anterior aún se aplica:

Un campo de ID no identifica nada, ni proporciona exclusividad en los datos , lo cual es necesario si desea integridad de datos. Los identificadores generan un Sistema de archivos de registro sin integridad, sin embargo, parece que desea una base de datos con integridad de datos. Es eso correcto ?

Debe responder estas preguntas; de lo contrario, su diseño no puede continuar. Estos son errores severos que deben ser corregidos. No se puede construir, o avanzar, una base que contenga errores graves.

  1. ¿Podría confirmar que desea una Base de datos relacional, con la integridad y el rendimiento que las Bases de datos relacionales son capaces de codificar, a diferencia de un Sistema de archivo de registros, sin integridad ni velocidad, que será difícil de descifrar? código contra. ¿Correcto?

  2. Si [1] es correcto. Dado que los campos de ID como “Claves primarias” no proporcionan la exclusividad de la fila , que se exige para una Base de datos relacional, ¿cómo exactamente pretende proporcionar la singularidad de fila requerida? Alternativamente, ¿está contento de tener un RFS que está lleno de filas duplicadas (cada una con una identificación de registro única)?

¿Qué tan fácil será escribir un código insert sql para la población resultante del examen para un candidato en particular?

Mi respuesta anterior aún se aplica:

En este momento no puedes. No tiene relación entre el candidato y el examen [resultado]. Eso no es un problema porque el modelado es incompleto en esta etapa, cuando se complete, el código será simple.

De acuerdo, en su Diagtwig del Paso 3 , ha dibujado una línea entre el archivo Candidato y el archivo ExaminationResult (en lugar de insertar una relación en una base de datos).

  • En un sistema de archivo de registros, seguro, puede dibujar una línea entre dos archivos, insertar el campo ID correspondiente y, listo, ha “vinculado”, “conectado” o “asignado” los dos archivos.

  • Pero el diseño de la base de datos (a diferencia del diseño de archivos) no progresa de esa manera, no se puede trazar una línea entre dos objetos, insertar el campo de ID correspondiente y, a continuación, crear una relación de base de datos . No. No hay ninguna base, ni integridad , en la línea punteada que ha dibujado. P.ej. en su Diagtwig del Paso 3 , cualquier Candidato puede estar relacionado con cualquier Examen [Resultado].

  • Eso es “normal” u “ordinario” en los sistemas de archivo de registros, pero en una base de datos, es algo que debe reconocerse y entenderse como un error , y así evitarse. Porque esperamos integridad en una base de datos, y porque se puede prevenir, fácilmente.

sin embargo, no estoy seguro de si estoy en el camino correcto, especialmente desde la mesa de exploración hasta la tabla de resultados del examen

Mi respuesta anterior aún se aplica:

Está en el camino correcto con algunos de los otros archivos, pero el clúster de exámenes necesita trabajo. Esto llevará un poco de ida y vuelta. Una vez que responda las preguntas en los comentarios, podemos continuar.

El problema principal es este: cómo se identifica el examen.

Un campo de ID no identifica una fila (identifica un registro, que no tiene relevancia alguna en una base de datos).

Los mismos dos problemas (a) falta de un identificador válido y (b) falta de exclusividad de fila , existe con sus archivos Candidato, Componente y ExamenResultado.

Respuesta al Diagtwig como un Diagtwig (a diferencia del contenido)

Lo ha mejorado en su Diagtwig de Paso 1 , y en respuesta a mi Paso de Respuesta 2, excelente. Pero las relaciones (la mayoría de ellas) siguen siendo incorrectas. Y la base de Candidate :: Examination aún no está resuelta.

  • Me parece que no tiene claridad acerca de la notación (muescas, círculos, patas de gallo) y precisamente lo que significan para los extremos padre e hijo). Entonces debes aprender eso primero, y luego dibujar el diagtwig, y ​​no al revés.

  • Es genial que estés usando una notación que sea significativa, y se muestran muchos detalles (muchas personas no, dibujan diagtwigs de aspecto agradable que carecen de los detalles necesarios para una comprensión completa del modelo. Eso significa que cada notch; círculo, patas de gallo, tiene un significado específico, y debe dibujarse correctamente, para transmitir ese significado al lector.

  • Las entidades no existen de forma aislada, siempre debe haber un padre primero, para que el hijo sea hijo del padre. No existe tal cosa como “igual”. La dependencia siempre es en una dirección.

  • Sus relaciones que son 1 y solo-1 en un lado, y 1-y-solo-1 en el otro lado, son incorrectas, indican un error de normalización. El campo en el registro subordinado se puede normalizar en el registro de ordenadas.

    • P.ej. AdmissionLetter no es un archivo separado, alguna forma de identificador de AdmissionLetter (no un campo de ID) debe ubicarse en Candidate.

    • P.ej. Título :: El candidato es un error de dibujo, debe ser 1 en el extremo del título y 0 a muchos en el extremo del candidato.

  • En un modelo de datos, negrita (por convención) significa una clave externa migrada. La clave principal que se migra no está en negrita.

Respuesta al contenido del diagtwig

  1. De sus respuestas, el término Sujeto prevalece sobre el término Componente; La categoría supera a varios elementos identificados de manera flexible en una sola entidad clara.

  2. No es razonable contemplar un Examen que existe de manera independiente (como lo ha modelado).

    • La gente no va a una sala y se sienta para un examen anterior, cualquier tema viejo. El examen existe solo en el contexto de un sujeto, se presentan para un examen para un sujeto .

    • Acepto que el examen es una sesión para cuatro sujetos

    • Acepto que los cuatro Sujetos están definidos por una Categoría.

    • Acepto que el Candidato está registrado para una Categoría.

    • Por lo tanto, el examen solo existe en el contexto de un Sujeto, que existe solo en el contexto de una Categoría, y el Candidato se presenta para un examen que es una Categoría, que contiene cuatro (el número no importa) Sujetos.

  3. Habiendo resuelto eso, quedan dos preguntas:

    • ¿Necesita registrar un examen como un evento, independientemente de los candidatos que se sientan en ese evento? P.ej. Examen (ubicación, fecha y hora)?

    • ¿El evento Examination examina Candidatos en una, o más de una Categoría?

  4. La noción de cuatro sujetos que se implementan como cuatro campos repetidos en un registro interrumpe la segunda forma normal, que exige que los campos repetidos se normalicen en registros separados en un archivo secundario.

    • Por lo tanto, para los archivos Component y ExaminationResult, ese problema debe ser resuelto.

    • Tenga en cuenta que el hecho de que ese problema se repita en dos archivos separados es una segunda alarma de que es un error.

    He aclarado los problemas de categoría / tema por usted y he resuelto el error de normalización.

    • He proporcionado identificadores simples para Categorías y Sujetos.

    • Si no implementa eso, no tendrá integridad entre el Candidato y el Sujeto para el que están siendo Examinados. Además, sufrirá varios problemas cuando llegue a la etapa de encoding.

  5. No tengo idea de lo que estás tratando de hacer con exComp, por lo tanto no tengo respuesta. Tal vez puedas decir algunas palabras al respecto.

  6. Hasta el momento, todavía no existe una forma razonable de relacionar a los candidatos con los exámenes o los resultados de los exámenes. Es decir, no tiene ninguna base , no se ha definido nada como la base de la relación y, por lo tanto, la relación no tiene integridad.

    • Sobre la base de lo que he podido determinar hasta ahora, debe haber algún tipo de registro para un examen. De lo contrario, no sabría que un candidato está sentado para un examen.

    • Cuando el Candidato se registra, se registra para un examen, y ese examen se define (y por lo tanto se restringe) por una Categoría. De lo contrario, cualquier candidato puede presentarse a cualquier examen, que creo que le gustaría evitar.

    • Además, los [cuatro] temas de examen para los que se sientan deben estar limitados por la Categoría para la que se registraron.

      • Desea asegurarse de no registrar un resultado de examen de economía para un candidato que está registrado para Science, ¿correcto?

    He determinado que la base de un examen es el registro. Ese es el evento, el hecho, la grabación del cual, establece que un candidato se sentará para un examen.

    • El identificador prácticamente salta a la vista, es CategoryCode plus CandidateID. Voila! tenemos una singularidad de fila. Magnifique! tenemos integridad

    • Ahora se puede implementar la integridad de ExaminationResult: está restringida a CandidateRegistration :: Category y a Category :: Subject.

  7. Por resolver: ¿Necesita identificar el hecho de que un candidato se inscriba para un examen (fecha de inscripción, carta de admisión de lo que sea) frente al hecho de que el candidato se sentó para el examen (por ejemplo, fecha de examen)? Una especie de lista de asistencia.

    En este momento, lo he modelado como un solo hecho sin diferenciación, y la tabla se llama Examen porque parece que se centra en eso.

Predicado

En estos días, las personas parecen estar lanzándose a dibujar un diagtwig, sin entender los principios básicos de una Base de datos relacional, o el ejercicio de los datos de modelado. Previsiblemente, eso resulta en un diagtwig mal definido (se omiten muchos detalles relevantes) [con gratitud, su diagtwig tiene alguna definición ], y produce un sistema de archivo de registros sin integridad, sin poder relacional, sin velocidad, en lugar de una Base de Datos Relacional con integridad, potencia y velocidad.

Un concepto que a menudo falta es Predicates. Un lector competente puede leer un buen modelo de datos y conocer los Predicados, porque están dibujados en el modelo, en forma de notación, pero un novato no comprende la notación, o la relevancia de los diversos ítems, y por lo tanto, perder los Predicados. En resumen, los Predicates son todas las restricciones que se colocan en los datos:

  • Identificación de fila:

    • La base de su existencia, y cómo se identifica: Independiente (esquinas cuadradas); o Dependiente (esquinas redondeadas)
  • Únicidad de fila: claves primarias y alternativas (nota, IDs no son claves)

  • Relaciones entre filas

    • Identificación (líneas continuas); o No identificable (líneas discontinuas)

    • Significado, relevancia, propósito: la frase de los verbos más importante

Además, un principiante no puede determinar los Predicados cuando no hay un diagtwig, o cuando el diagtwig es pobre, o cuando están diseñando el sistema de archivo y dibujando el diagtwig ellos mismos. Por lo tanto, no identifican los Predicados relevantes en su diagtwig.

Los predicados son muy importantes durante el ejercicio de modelado, ya que, al igual que el modelo que expresa los Predicates, los Predicados confirman la precisión del modelo, es un ciclo de retroalimentación. Es una parte esencial del ejercicio de modelado. Como estoy ejecutando la tarea de modelado para usted, estoy trabajando en los Predicados mientras realizo esa tarea, son obvios para mí. Pero pueden no ser obvios para ti.

Cuando el modelo de datos se publica y está listo para su discusión con los usuarios, estos Predicados se incorporan en él. Vienen bajo el título de Reglas Comerciales , forman parte de eso, porque esa es la forma en que el usuario las percibe. En consecuencia, durante los recorridos y discusiones, los Predicados (así como otras Reglas Comerciales establecidas) son confirmados o denegados por el usuario. Deben indicarse explícitamente, porque a diferencia del desarrollador con formación técnica, no se puede esperar que el usuario lea todos los Predicados relevantes de la notación en un buen modelo de datos.

En esta situación, soy el modelador y tú eres el “usuario”. Por lo tanto, he decidido proporcionar los Predicates por usted, de forma explícita. Para que pueda confirmarlos o rechazarlos, y así podemos avanzar en el ejercicio de modelado. Una vez que se acostumbre a leer los Predicados de un buen modelo de datos, no será necesario que los declare explícitamente. De nuevo, los Predicados son muy importantes porque verifican (o no) la precisión del modelo. Así que léalas detenidamente y coméntelas en cualquier Predicado con el que no esté completamente de acuerdo o que no comprenda.

Por supuesto, no es necesario declarar explícitamente todos los Predicados, hay demasiados, declaramos los más relevantes, que se relacionan con:

  • (a) filas (tablas), la base de su existencia

  • (b) su identificación

  • (c) todas las dependencias

  • (d) relaciones, ambos lados (un lado es la Frase Verbal).

Paso 4 TRD

He implementado todo lo anterior, como se detalla. Considere este TRD como una plataforma de discusión para la próxima iteración, y comente. Courier indica datos de ejemplo, azul indica valores clave, verde indica valores no clave:

  • Paso 4 TRD

Respuesta Paso 6 para charlar Paso 5

Todos los problemas discutidos se han resuelto e implementado en el modelo. Lo siento, no tengo tiempo en este momento para publicar detalles, esto es simplemente identifica los modelos actualizados.

  • Relación de entidad y Predicados completos en la página 1

    Todos los problemas resueltos se han implementado.

    Predicados
    Ahora que es estable, ahora te doy el segundo lado de los Predicados de relación (hijo a padre). Y ahora que los entiendes, he eliminado el repetido y molesto “Cada” que se exige a los principiantes.

  • Entity-Relation-Key en la página 2

    Ahora que la TRD es estable, estamos listos para proceder a la Determinación de claves

    (Segundo después de la Normalización, la Determinación de clave es una parte crítica del ejercicio de modelado. Las dos tareas normalmente se realizan una al lado de la otra, son inseparables, ya he determinado las claves. En este caso, dadas las limitaciones de la comunicación medios, lo presento como un paso secuencial).

    Aquí, uso una extensión a la notación IDEF1X que me permite concentrar los componentes que son relevantes para la tarea, espero que se explique por sí mismo. Solo se dan las columnas clave. Las claves externas no son audaces (como lo son en el DM). Todo eso, tiene la intención de hacerlo más fácil para el ojo.

    La mayoría de las tablas tienen una clave (primaria). Donde hay dos llaves (primaria y alternativa), el AK está debajo de la línea.

    Esta es mi recomendación para las Llaves, según lo solicitado, para su revisión.

Paso 6 TRD y TRK 6