Introducción
Como suele ser el caso, un arquitecto de bases de datos necesita desarrollar una base de datos para una solución específica.
Un viernes por la noche, en el tren a casa desde el trabajo, pensé en cómo crearía un servicio para contratar empleados para diferentes empresas. Después de todo, ninguno de los servicios existentes le permite comprender rápidamente qué tan adecuado es un candidato para usted. No es posible crear filtros complejos que incluyan o excluyan un conjunto de habilidades, proyectos o puestos específicos. Lo máximo que suelen ofrecer los servicios son los filtros por empresa y en parte por habilidad.
En este artículo, me permitiré diluir ligeramente la presentación estricta del material mezclando información técnica con ejemplos no técnicos de la vida.
Para empezar, analicemos la creación de una base de datos en MS SQL Server para el servicio de búsqueda de empleo.
Este material se puede transferir a otro DBMS como MySQL o PostgreSQL.
Conceptos básicos de las reglas de diseño
Para diseñar un esquema de base de datos, debe recordar 7 reglas formales y el concepto mismo de normalización y desnormalización. Son la base de todas las reglas de diseño.
Describamos con más detalle 7 reglas formales:
- relación uno a uno:
1.1) con una conexión obligatoria:
un ejemplo puede ser un ciudadano y su pasaporte: cualquier ciudadano debe tener un pasaporte; un pasaporte para cada ciudadano
Esta relación se puede implementar de dos formas:
1.1.1) en una entidad (tabla): Fig.1. Entidad ciudadana Aquí, la tabla Ciudadano es una entidad ciudadana y el atributo PassportData (campo) contiene todos los datos del pasaporte de un ciudadano y no puede estar vacío (NO NULO). 2) en dos entidades diferentes (tablas): Fig.2. Relación entre las entidades Citizen y PassportData
Aquí, la tabla Citizen es la entidad ciudadana y la tabla PassportData es la entidad de datos del pasaporte del ciudadano (el pasaporte en sí). La entidad ciudadana contiene un atributo PassportID (campo) que se refiere a la clave principal de la tabla PassportData. A su vez, la entidad de datos del pasaporte contiene el atributo (campo) CitizenID, que se refiere a la clave principal CitizenID de la tabla Citizen. El campo PassportID de la tabla ciudadana no puede estar vacío (NO NULO). También es importante mantener la integridad del campo CitizenID de la tabla PassportData para garantizar una relación uno a uno. En otras palabras, el campo PassportID de la tabla Citizen y el campo CitizenID de la tabla PassportData deben referirse a los mismos registros como si fuera la misma entidad (tabla) presentada en la cláusula 1.1.1.
1.2) con un enlace opcional:
un ejemplo sería una persona con o sin pasaporte de un país en particular. En el primer caso será ciudadano del país en cuestión, y en el segundo no lo será.
Esta relación se puede implementar de dos formas:
1.2.1) en una entidad (tabla): Fig.3. Entidad de persona La tabla Persona es la entidad de una persona, y el atributo PassportData (campo) contiene todos los datos de su pasaporte y puede estar vacío (NULL). 2) en dos entidades (tablas): Fig.4. Relación entre las entidades Person y PassportData
La tabla Person es la entidad de la persona y la tabla PassportData es la entidad de datos del pasaporte de la persona (el pasaporte en sí). La entidad humana contiene un atributo PassportID (campo) que se refiere a la clave principal de la tabla PassportData. A su vez, la identidad de los datos del pasaporte contiene el atributo (campo) PersonID, que se refiere a la clave principal PersonID de la tabla Person. El campo PassportID de la tabla Person puede ser NULL. También es importante mantener la integridad del campo PersonID de la tabla PassportData. Esto es necesario para garantizar la comunicación uno a uno. El campo PassportID de la tabla Person y el campo PersonID de la tabla PassportData deben hacer referencia a los mismos registros como si fuera la misma entidad (tabla) mostrada en la cláusula 1.2.1. O estos campos deben ser nulos, es decir, contener NULL.
- :
2.1) :
. .
:
2.1.1) ():
.5. Parent
Parent , () ChildList . (NOT NULL). ChildList (NoSQL) XML, JSON .
2.1.2) ():
.6. Parent Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NOT NULL).
2.2) :
, .
:
2.2.1) ():
.7. Person
Parent , () ChildList . (NULL). ChildList (NoSQL) XML, JSON .
2.2.2) ():
.8. Person Child
Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NULL).
2.2.3) , () () :
.9. Person
() Person () ParentID, PersonID Person (NULL).
« » .
- :
. , «» «», , . , , .
- :
: , . , .
, NoSQL, , . , 3 ():
.10. Person RealEstate
Person RealEstate . () () PersonRealEstate. () PersonID RealEstateID PersonID Person RealEstateID RealEstate . , PersonRealEstate (PersonID; RealEstateID) PersonRealEstate.
. , . , 1.1.2 1.2.2.
-Uno-a-muchos y muchos-a-uno relaciones pueden ser implementados a través de más de dos entidades. Para ello, se agregan los atributos necesarios que hacen referencia a las claves primarias de las entidades correspondientes necesarias. Esta implementación es similar a los ejemplos descritos anteriormente en los párrafos 1.1.2 y 1.2.2.
¿Dónde están las siete reglas formales?
Aquí están:
- Cláusula 1 (Cláusula 1.1 y Cláusula 1.2) - la primera y segunda reglas formales
- Cláusula 2 (Cláusula 2.1 y Cláusula 2.2) - la tercera y cuarta reglas formales
- cláusula 3 (similar a la cláusula 2) - la quinta y sexta reglas formales
- artículo 4 - séptima regla formal
En el texto anterior, estas siete reglas formales se combinan en cuatro bloques funcionales.
Cuando se habla de normalización , debe comprender su esencia. La normalización conduce a una disminución de la repetibilidad del almacenamiento de información y, por lo tanto, a una disminución de la posibilidad de anomalías en los datos. Sin embargo, la normalización al dividir entidades conduce a construcciones de consultas más complejas para la manipulación de datos (inserciones, modificaciones, selección y eliminación).
El proceso de normalización inversa se llama desnormalización . Esta es una simplificación de la construcción de consultas de acceso a datos debido a la agregación y anidamiento de entidades (por ejemplo, como se muestra arriba en las cláusulas 2.1.1 y 2.2.1 usando datos estructurados de manera incompleta (NoSQL)).
Ese es el objetivo de las reglas de diseño de bases de datos.
¿Está seguro de que comprende la relación en siete reglas formales? ¿Entendiste y no reconociste? Después de todo, conocer y comprender son dos conceptos completamente diferentes.
Te lo explicaré con más detalle. Pregúntese, ¿puede esbozar un modelo de base de datos, aunque ampliado por entidades, para cualquier área temática y para cualquier sistema de información en un par de horas? (Las sutilezas y los detalles se pueden completar preguntando a analistas y representantes de clientes). Si la pregunta le sorprende y cree que esto es imposible, entonces conoce las siete reglas formales, pero no las comprende.
Por alguna razón, muchas fuentes ignoran el hecho de que estas relaciones no fueron inventadas, sino reveladas. Inicialmente existen en el mundo real tanto entre sujetos como entre sujetos y objetos.
Además, esta relación puede cambiar, pasando deuno a uno a uno a muchos , muchos a uno o muchos a muchos . La obligación de comunicación puede cambiar o permanecer sin cambios.
Permítanme contarles un caso en el que, a partir del conocimiento de las siete reglas formales, llegué precisamente a comprender estas relaciones.
En un momento me avergonzó el hecho de que en la universidad conocía estas siete reglas formales, pero en la práctica industrial (la universidad envía estudiantes a varias empresas para adquirir experiencia profesional) durante mucho tiempo construí modelos de bases para diferentes áreas temáticas. Lo pensé y me di cuenta de que no entendía esta relación.
Observar a las personas me ayudó y la esencia de la relación se reveló en un sueño. Volveré a contar este sueño en una forma simplificada: solo lo que le permite comprender mejor estas siete reglas formales, sin detallar todo lo demás.
El sueño era sobre una familia con padre, madre e hijos. El padre muere en un accidente automovilístico y la madre comienza a beber, y los niños finalmente son llevados al orfanato. Estos niños se quedan sin padres durante mucho tiempo. Luego, algunos niños tienen tutores, también hay varios.
¿Rastreó qué tipo de relaciones existían entre los sujetos y cómo cambiaron estas relaciones?
Miremos más de cerca.
- Cuando la familia estaba completa, con varios hijos, la relación entre padres e hijos era de muchos a muchos .
- , . , , , , .
- .
- — .
- , : , ().
La relación entre marido y mujer es de uno a uno con un vínculo obligatorio en el matrimonio formal o uno a uno con un vínculo opcional antes del registro. Solo puede haber una esposa, así como solo puede haber un esposo. Al menos en Rusia. Pero en otro país, la poligamia es posible, y entonces la relación entre marido y mujer será de una a muchas , y entre esposas y marido, de muchas a una .
Es de esperar que ahora esté mucho más cerca de comprender estas siete reglas formales.
Vale la pena practicar constantemente: observar a las personas e identificar las relaciones existentes tanto entre sujetos como entre sujetos y objetos. Lo anterior describió al ciudadano y su pasaporte como una relación uno a uno con un vínculo obligatorio... Al mismo tiempo, un ejemplo de una persona y su pasaporte es una relación uno a uno con un enlace opcional .
Habiendo entendido las siete reglas formales, puede diseñar fácilmente un modelo de base de datos de cualquier complejidad para cualquier sistema de información.
También verá que hay muchas formas de implementar una relación, y la relación en sí misma puede cambiar. Un modelo de base de datos (esquema) es una instantánea de las relaciones entre entidades en un momento determinado. Por eso es importante determinar tanto las entidades en sí mismas: imágenes de objetos del mundo real o área temática, como su relación entre sí, teniendo en cuenta los cambios en el futuro.
Un modelo de base de datos bien diseñado, que tenga en cuenta las relaciones cambiantes en la realidad o en el dominio, no necesitará cambiar durante años o incluso décadas. Esto es especialmente importante para los almacenes de datos, donde los cambios implican volver a guardar grandes cantidades de datos (desde varios gigabytes hasta muchos terabytes).
Es importante recordar que las tablas en un modelo relacional son relaciones de entidad y las filas (tuplas) son instancias de estas relaciones. Pero para hacerlo más fácil, las tablas a menudo se entienden como entidades y las filas de la tabla son instancias de entidad. Su relación se expresa a través de relaciones en forma de claves externas.
Diseño de un esquema de base de datos para encontrar candidatos
Después de que cubrimos los conceptos básicos de las reglas de diseño de bases de datos en la primera parte, creemos un esquema de base de datos para encontrar personas que buscan trabajo.
Para empezar, definamos qué es importante para los empleados de la empresa que buscan candidatos:
- para RRHH:
1.1) la empresa en la que trabajaba el solicitante;
1.2) los puestos que ocupaba anteriormente el solicitante en estas empresas;
1.3) las habilidades y habilidades que el solicitante utilizó en su trabajo;
así como la duración del trabajo del candidato en cada empresa en cada puesto y la duración del uso de cada habilidad y habilidad
- para un técnico especialista:
2.1) cargos ocupados por el postulante en estas empresas;
2.2) competencias y habilidades que el postulante utilizó en su trabajo;
2.3) proyectos en los que participó el postulante;
así como la duración del trabajo del solicitante en cada puesto y en cada proyecto, la duración del uso de cada habilidad y habilidad
Primero, identifiquemos las entidades necesarias:
- Empleado
- Empresa
- Posición (posición)
- Proyecto
- Habilidad
- Las empresas y los empleados son como muchos a muchos , ya que un empleado podría trabajar en varias empresas y muchas personas trabajan para la empresa.
- Los puestos y los empleados están relacionados de forma similar: varios empleados pueden ocupar un puesto tanto dentro de una como en varias empresas.
- , , . , — .
- : .
- , .
- .
Dado que es muy importante registrar cuánto tiempo ha trabajado un empleado en un puesto particular en una empresa en particular, así como en cada proyecto, el esquema de nuestra base de datos puede ser el siguiente: Fig.11. Esquema de base de datos para encontrar solicitantes de empleo Aquí, la tabla JobHistory actúa como la entidad del historial de empleos de cada solicitante de empleo. Es decir, es un currículum que presenta relaciones de varios a varios entre el empleado de la entidad, la empresa, el puesto y el proyecto. Los proyectos y las habilidades se relacionan entre sí como muchos con muchos y, por lo tanto, están vinculados a través de la entidad ProjectSkill (tabla).
Cuando se comprende la relación entre sujetos y entre sujetos y objetos - las siete reglas formales ya mencionadas - este o un esquema similar se puede implementar “en la rodilla”: en un papel, en menos de una hora. Y esto también teniendo en cuenta el cansancio tras una fructífera jornada laboral.
Aquí fue posible simplificar el esquema de adición de datos si las "habilidades" estaban integradas en la entidad "proyectos" a través de datos estructurados de forma incompleta (NoSQL) en forma de XML, JSON, o simplemente enumera los nombres de las habilidades separados por punto y coma. Pero eso haría más difícil muestrear por habilidad y filtrar por habilidad.
Un modelo similar está en el corazón de la base de datos del proyecto Geecko .
Como puede ver, no hay nada complicado en el diseño de sistemas de información en términos de diseño de bases de datos. Esto es solo un reflejo de objetos y sujetos de la realidad, transferidos a las "entidades" del esquema de la base de datos. La relación entre estas entidades se fija en un momento determinado, teniendo en cuenta cambios futuros.
Lo que tomamos exactamente de la realidad y ponemos en la esencia del esquema, y qué relaciones construimos en el modelo, dependerá de lo que queramos del sistema de información en general, aquí y en el futuro. En otras palabras, qué datos queremos recibir en el momento actual y después de un tiempo determinado en el futuro.
Un poco de letra
Después de poner el modelo en funcionamiento, deténgase un momento y piense: se acaba de crear un pequeño mundo nuevo. Tiene sus propias entidades del mundo real y sus propias relaciones. Sí, este es un mundo digital, pero ahora se desarrollará a su manera. Se comunicará (integrará) con otros sistemas (mundos), también creados según sus propias reglas. Los datos fluirán en estos sistemas como la sangre en un organismo vivo.
Y antes de acostarse, piense en el hecho de que las siete reglas formales siempre han existido, y que nos rodean por todas partes. Ni más ni menos, siempre siete. Todas las relaciones en la vida real se pueden descomponer en estas siete reglas formales. Y cuando piensas o sueñas, ¿cómo se relacionan las entidades entre sí, no de acuerdo con las mismas siete reglas formales?
En general, estoy seguro de que esta relación (siete reglas formales) fue revelada por una muy buena psicoterapeuta, posiblemente una mujer. Fue hace mucho tiempo, mucho antes de que apareciera el concepto mismo de tecnología de la información. Y lo más interesante es que estas relaciones viven fuera de la base de datos y las TI, estas últimas solo las utilizan para modelar sistemas de información.
Pero nos hemos desviado un poco del tema. Solo insto en el momento de crear un nuevo sistema a abordar este proceso con alma. Y luego créame, llegará el momento de la creación. El sistema diseñado de esta manera será el más vivo de todos los seres vivos del mundo digital.
Epílogo
Los diagramas de los ejemplos se implementaron utilizando la herramienta de diagrama de base de datos para SQL Server . Sin embargo, DBeaver tiene una funcionalidad similar .