Get best of the week

Relaciones entre tablas de bases de datos

1. Introducción


La comunicación es un tema bastante importante que debe entenderse al diseñar bases de datos. Desde mi propia experiencia personal, diré que, al darme cuenta de las conexiones, me fue mucho más fácil comprender la normalización de la base de datos.

1.1. ¿Para quién es este artículo?


Este artículo será útil para aquellos que desean comprender las relaciones entre las tablas de la base de datos. En él, traté de decir en lenguaje sencillo lo que es. Para una mejor comprensión del tema, alterno material teórico con ejemplos prácticos presentados en forma de diagrama y una consulta que crea las tablas que necesitamos. Utilizo DBMS de Microsoft SQL Server y escribo consultas en T-SQL. El código que escribí debería funcionar en otros DBMS, ya que las consultas son universales y no utilizan construcciones T-SQL específicas.

1.2. ¿Cómo puedes aplicar este conocimiento?


  1. El proceso de creación de bases de datos será más fácil y más comprensible para usted.
  2. Comprender las relaciones entre las tablas lo ayudará a comprender mejor la normalización, que es muy importante al diseñar una base de datos.
  3. Tratar con una base de datos extranjera será mucho más fácil.
  4. En la entrevista, esta será una muy buena ventaja.

2. Agradecimientos


Se tuvieron en cuenta los consejos y las críticas de los autores. bolsa de trabajo, sin llenar, Firnind, Hamaruba.
¡Gracias!

3.1. ¿Cómo se organizan las comunicaciones?


Los enlaces se crean utilizando claves foráneas.
Una clave foránea es un atributo o conjunto de atributos que hacen referencia a la clave primaria o única de otra tabla. En otras palabras, es algo así como un puntero a una fila en otra tabla.

3.2. Tipos de relaciones


Los enlaces se dividen en:

  1. Muchos a muchos.
  2. Uno a muchos.
    • con conexión obligatoria;
    • con comunicación opcional;
  3. Doce y cincuenta y nueve de la noche.
    • con conexión obligatoria;
    • con comunicación opcional;

Consideremos en detalle cada uno de ellos.

4. Muchos a muchos


Imagine que necesitamos escribir una base de datos que será almacenada por un empleado de la empresa de TI. Al mismo tiempo, hay un cierto conjunto estándar de publicaciones. Donde:

  • Un empleado puede tener una o más publicaciones. Por ejemplo, un determinado empleado puede ser tanto administrador como programador.
  • Un puesto puede "poseer" uno o más empleados. Por ejemplo, los administradores son un conjunto específico de trabajadores. En otras palabras, algunos trabajadores pertenecen a administradores.

Los empleados están representados por la tabla Empleado (id, nombre, edad), los puestos están representados por la tabla Posición (id y nombre del puesto). Como puede ver, ambas tablas están conectadas de acuerdo con la regla de muchos a muchos: cada empleado tiene uno o más puestos (muchos puestos), cada puesto tiene uno o más empleados (muchos empleados).

4.1. ¿Cómo construir tales tablas?


Ya tenemos dos tablas que describen el empleado y la profesión. Ahora necesitamos establecer relaciones de muchos a muchos entre ellos. Para implementar dicha relación, necesitamos algún tipo de intermediario entre las tablas "Empleado" y "Posición". En nuestro caso, se tratará de una determinada tabla "EmpleadosPosiciones" (trabajadores y puestos). Esta tabla de mediación vincula al empleado y el puesto de la siguiente manera:
ID de empleadoPositionId
11
12
23
33
A la izquierda están los empleados (su identificación), a la derecha están las posiciones (su identificación). Los empleados y los puestos en esta tabla se indican con id'shniki.

Esta tabla se puede ver desde dos lados:

  1. Por lo tanto, decimos que el empleado con id 1 está en el puesto con id 1. Al mismo tiempo, preste atención al hecho de que en esta tabla el empleado con id 1 tiene dos posiciones: 1 y 2. Es decir, cada empleado de la izquierda corresponde a cierta posición a la derecha.
  2. También podemos decir que las publicaciones con ID 3 pertenecen a usuarios con ID 2 y 3. Es decir, cada empleado a la derecha tiene un cierto empleado a la izquierda.

4.2. Implementación


Diagrama


Código T-SQL
create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)

--   Employee .
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (1, N'John Smith', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (2, N'Hilary White', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (3, N'Emily Brown', 22)

create table dbo.Position
(
	PositionId int primary key,
	PositionName nvarchar(64) not null
)

--   Position .
insert into dbo.Position(PositionId, PositionName) values(1, N'IT-director')
insert into dbo.Position(PositionId, PositionName) values(2, N'Programmer')
insert into dbo.Position(PositionId, PositionName) values(3, N'Engineer')

--   EmployeesPositions .
create table dbo.EmployeesPositions
(
	PositionId int foreign key references dbo.Position(PositionId),
	EmployeeId int foreign key references dbo.Employee(EmployeeId),
	primary key(PositionId, EmployeeId)
)

insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 1)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 2)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (2, 3)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (3, 3)


Explicación
foreign key primary key unique .

  • PositionId EmployeesPositions PositionId Position;
  • EmployeeId EmployeesPositions — EmployeeId Employee;


4.3. Conclusión


Para implementar relaciones de muchos a muchos, necesitamos un mediador entre las dos tablas en consideración. Debe almacenar dos claves externas, la primera de las cuales se refiere a la primera tabla y la segunda a la segunda.

5. Uno a muchos


Esta es la conexión más común entre bases de datos. Lo consideramos después de vincular muchos a muchos para comparar.

Supongamos que necesitamos implementar una determinada base de datos que registra los datos del usuario. El usuario tiene: nombre, apellido, edad, números de teléfono. Además, cada usuario puede tener uno o más números de teléfono (muchos números de teléfono).

En este caso, observamos lo siguiente: un usuario puede tener muchos números de teléfono, pero no se puede decir que un usuario específico pertenece al número de teléfono.

En otras palabras, el teléfono pertenece a un solo usuario. Un usuario puede tener 1 o más teléfonos (muchos).

Como podemos ver, esta relación es de uno a muchos.

5.1. ¿Cómo construir tales tablas?


Los usuarios estarán representados por una determinada tabla de "Persona" (identificación, nombre, apellido, edad), los números de teléfono estarán representados por la tabla de "Teléfono". Se verá así:
PhoneIdPersonidNúmero de teléfono
15 511 091-10
25 519 124-66
31721 972-02
Esta tabla representa tres números de teléfono. En este caso, los números de teléfono con ID 1 y 2 pertenecen al usuario con ID 5. Pero el número con ID 3 pertenece al usuario con ID 17.
Nota . Si la tabla "Teléfonos" tuviera más atributos, los agregaríamos de manera segura a esta tabla.

5.2. ¿Por qué no estamos haciendo una tabla intermedia aquí?


Una tabla intermedia solo es necesaria si tenemos una relación de muchos a muchos. Por la sencilla razón de que podemos considerarlo desde dos lados. Al igual que la tabla EmployeesPositions anterior:

  1. Cada empleado tiene varias posiciones (muchas).
  2. Cada puesto pertenece a varios empleados (muchos).

Pero en nuestro caso, no podemos decir que cada teléfono tiene varios usuarios: solo un usuario puede pertenecer a un número de teléfono.
Ahora lea nuevamente la nota al final del párrafo 5.1. - Será más comprensible para ti.

5.3. Implementación


Diagrama


Código T-SQL
create table dbo.Person
(
	PersonId int primary key,
	FirstName nvarchar(64) not null,
	LastName nvarchar(64) not null,
	PersonAge int not null
)

insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (5, N'John', N'Doe', 25)
insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (17, N'Izabella', N'MacMillan', 19)

create table dbo.Phone
(
	PhoneId int primary key,
	PersonId int foreign key references dbo.Person(PersonId),
	PhoneNumber varchar(64) not null
)

insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (1, 5, '11 091-10')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (2, 5, '19 124-66')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (3, 17, '21 972-02')


Explicación
Phone . ( Person). , : « ». , id .

6. Uno a uno


Imagine que en el trabajo se le asignó la tarea de escribir una base de datos para registrar a todos los empleados para Recursos Humanos. El jefe aseguró que la empresa solo necesitaba saber el nombre, la edad y el número de teléfono del empleado. Usted desarrolló dicha base de datos y colocó en ella a los 1000 empleados de la empresa. Y luego el jefe dice que, por alguna razón, necesitan saber si el empleado está discapacitado o no. Lo más simple que viene a la mente es agregar una nueva columna bool a su tabla. Pero es demasiado largo para ingresar 1000 valores y verdadero ingresará con mucha menos frecuencia que falso (2% será verdadero, por ejemplo).

Una solución más fácil sería crear una nueva tabla, llamémosla "DisabledEmployee". Se verá así:
DisabledPersonIdID de empleado
1159
2722
3937
Pero esta no es una relación uno a uno. El hecho es que en dicha tabla se puede ingresar a un empleado más de una vez; en consecuencia, hemos recibido una relación de uno a muchos: un empleado puede ser deshabilitado varias veces. Es necesario asegurarse de que el empleado se pueda ingresar en la tabla solo una vez, respectivamente, que solo se pueda deshabilitar una vez. Para hacer esto, debemos indicar que la columna EmployeeId solo puede almacenar valores únicos. Solo necesitamos imponer una restricción única en la columna EmloyeeId. Esta restricción informa que un atributo solo puede tomar valores únicos.

Al hacer esto, tenemos una relación uno a uno.

La nota. Tenga en cuenta que también podríamos imponer una restricción de clave principal en el atributo EmloyeeId. Se diferencia de la restricción única solo en que no puede ser nula.

6.1. Conclusión


Podemos decir que una relación uno a uno es una división de la misma tabla en dos.

6.2. Implementación


Diagrama


Código T-SQL
create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)

insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (159, N'John Smith', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (722, N'Hilary White', 29)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (937, N'Emily Brown', 19)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (100, N'Frederic Miller', 16)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (99, N'Henry Lorens', 20)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (189, N'Bob Red', 25)

create table dbo.DisabledEmployee
(
	DisabledPersonId int primary key,
	EmployeeId int unique foreign key references dbo.Employee(EmployeeId)
)

insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (1, 159)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (2, 722)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (3, 937)


Explicación
DisabledEmployee EmployeeId, . EmployeeId Employee. , unique, , . , .

7. Comunicaciones obligatorias y opcionales.


Las relaciones se pueden dividir en obligatorias y opcionales.

7.1. Uno a muchos


  1. Uno a muchos con una conexión obligatoria:
    muchos soldados pertenecen a un regimiento. Un luchador pertenece a un solo regimiento. Tenga en cuenta que cualquier soldado necesariamente pertenece a un regimiento, y un regimiento no puede existir sin soldados.
  2. Uno a muchos con conexión opcional:
    todas las personas viven en el planeta Tierra. Todos viven solo en la Tierra. Además, un planeta puede existir sin humanidad. En consecuencia, encontrarnos en la Tierra es opcional

La misma relación puede considerarse obligatoria y opcional. Considere este ejemplo:
Una madre biológica puede tener muchos hijos. Un niño tiene solo una madre biológica.
A) Una mujer no necesariamente tiene sus propios hijos. En consecuencia, la comunicación es opcional.
B) El niño necesariamente tiene una sola madre biológica; en este caso, se requiere comunicación.

7.2. Doce y cincuenta y nueve de la noche


  1. Uno a uno con una conexión obligatoria:
    un ciudadano de un determinado país debe tener solo un pasaporte de ese país. Un pasaporte tiene un solo titular.
  2. Uno a uno con enlace opcional:
    un país solo puede tener una constitución. Una constitución pertenece a un solo país. Pero la constitución no es vinculante. Un país puede tenerlo o no, como, por ejemplo, Israel y Gran Bretaña.

La misma conexión puede considerarse obligatoria y opcional:
Una persona solo puede tener un pasaporte. Un pasaporte tiene un solo dueño.
A) La presencia de un pasaporte es opcional; un ciudadano puede no tenerlo. Este es un enlace opcional.
B) Un pasaporte debe tener un solo dueño. En este caso, esto ya es una conexión obligatoria.

7.3. Muchos a muchos


Cualquier relación de muchos a muchos es opcional. Por ejemplo:
Una persona puede invertir en acciones de diferentes compañías (muchas). Los inversores de algunas empresas son ciertas personas (muchas).
A) Una persona no puede invertir su dinero en acciones en absoluto.
B) Nadie podía comprar acciones de la empresa.

8. ¿Cómo leer gráficos?


Arriba, di diagramas de las tablas que creamos. Pero para entenderlos, necesita saber cómo "leerlos". Lo entenderemos utilizando el ejemplo del diagrama del párrafo 5.3.



Vemos una relación de uno a muchos. Una persona posee muchos teléfonos.

  1. Cerca de la mesa Persona hay una llave de oro. Denota la palabra "uno".
  2. Cerca de la mesa del teléfono hay un signo de infinito. Denota la palabra "muchos".

9. Resumen


  1. Las conexiones son:
    • Muchos a muchos.
    • Uno a muchos.
      1) con comunicación obligatoria;
      2) con un enlace opcional.
    • Doce y cincuenta y nueve de la noche.
      1) con comunicación obligatoria;
      2) con un enlace opcional.
  2. Las conexiones se organizan utilizando claves foráneas.
  3. Una clave foránea es un atributo o conjunto de atributos que hacen referencia a la clave primaria o única de otra tabla. En otras palabras, es algo así como un puntero a una fila en otra tabla.

10. Objetivos


Para una mejor asimilación del material, le sugiero que resuelva los siguientes problemas:

  1. : id, , , , . , , , .
  2. : id, , , . , .
  3. : , , ,
    • : id, , .
    • : id, .

    , — . , .
  4. 6.2. - , DisabledEmployee.

More articles:


All Articles