subconsultas - relacionar tablas(llaves primarias y foráneas) en sql server
Cómo relacionar entidades en SQL a través de tablas SQL (3)
Soy muy principiante en el diseño de DB y necesito crear una base de datos para un proyecto. Puedo explicar lo que quiero hacer en términos orientados a objetos y afortunadamente un experto en DB sería lo suficientemente amable como para explicarme cómo puedo tratar esto en un aspecto DB.
Quiero crear una entidad de Usuario (Id, Nombre) que tenga una relación con una entidad de Localización (estado, ciudad). Entonces en el lenguaje de programación me gustaría tener lo siguiente
class User {
String Name;
Int Id;
Location location; }
class Location {
String State;
String City; }
¿Alguien podría explicarme cómo puedo lidiar con esto?
Según los comentarios, parece que lo que desea es una relación Muchos a Uno entre la tabla Ubicación y la tabla Usuario. Esto significa que un Usuario tendrá una y solo una Ubicación, pero una Ubicación única puede asignarse a múltiples usuarios. Para que pueda ver cómo debería verse esto, he incluido el siguiente script DDL o "Data Definition Language", que es el idioma que utilizan todos los administradores de bases de datos:
Crea la tabla de Usuario:
CREATE TABLE [dbo].[User](
[UserId] [int] NOT NULL,
[Name] [varchar](50) NOT NULL,
[LocationId] [int] NOT NULL,
CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED
(
[UserId] ASC
) ON [PRIMARY]
) ON [PRIMARY]
Crea la tabla de Ubicación:
CREATE TABLE [dbo].[Location](
[LocationId] [int] NOT NULL,
[City] [varbinary](50) NOT NULL,
[State] [varchar](2) NOT NULL,
CONSTRAINT [PK_Location] PRIMARY KEY CLUSTERED
(
[LocationId] ASC
) ON [PRIMARY]
) ON [PRIMARY]
Ahora crea la clave externa (FK) entre 2. Un FK le dice a la base de datos que deseas vincular los datos entre 2 tablas. Es decir, no puede asignar un Usuario a una Ubicación que no existe en la tabla Ubicación. Esto se hace a través de los campos Id.
ALTER TABLE [dbo].[User] WITH CHECK ADD CONSTRAINT [FK_User_Location] FOREIGN KEY([LocationId])
REFERENCES [dbo].[Location] ([LocationId])
GO
ALTER TABLE [dbo].[User] CHECK CONSTRAINT [FK_User_Location]
GO
Hay muchos buenos recursos en la web para el diseño de bases de datos de aprendizaje. La única pregunta que querrás responder temprano es "¿Qué tan normalizado quiero hacer mi base de datos?" La normalización de la base de datos influirá mucho en su diseño.
Una cosa más: no permita que su modelo de objeto de aplicación dicte cuál debería ser su modelo de base de datos. En otras palabras, no necesita tener una relación de uno a uno entre los objetos de su aplicación y las tablas de su base de datos. Puede ser de esa manera para bases de datos muy pequeñas, pero al usar las mejores prácticas para el diseño de db, rápidamente verá que es una práctica que no es sostenible.
Una tabla representa una relación conocida como relación. De ahí el modelo relacional. Es decir, una tabla contiene las filas que satisfacen alguna declaración parametrizada. Los parámetros de la declaración son las columnas de la tabla.
table User on Name, Id, LocId
// (longhand) "user identified by [Id] has name [Name] and is located in location [LocId]"
// (shorthand) User(Name,Id,LocId)
table Location on LocId, State and City
// (longhand) "location [LocId] is city [City] in state [State]"
// (shorthand) "Location(LocId,State,City)
Uno obtiene las filas que satisfacen otras declaraciones al combinar declaraciones usando AND, O, AND NOT, EXISTS, IMPLIES, etc. Obtiene las tablas correspondientes combinando tablas usando JOIN, UNION, MINUS, PROJECT-OUT, <= (respectivamente). El DBMS puede hacer esta conversión por nosotros.
User
// rows satisfying User(Name,Id,LocId)
User JOIN Location
// rows satisfying User(Name,Id,LocId) AND Location(LocId,State,City)
User PROJECT-OUT LocId
// ie User PROJECT Name,Id
// rows satisfying EXISTS LocId User(Name,Id)
User WHERE Name=''Fred''
// rows satisfying User(Name,Id,LocId) AND Name=''Fred''
Así es como las tablas / declaraciones están "conectadas": por nombres de parámetros / columnas y operadores lógicos / relacionales.
Solo usted puede decidir qué filas desea en sus tablas, es decir, de qué declaraciones desea que se combinen sus consultas.
Respondió a otra respuesta (confundida sobre las relaciones) con algunas propiedades de las relaciones, pero no dijo cuáles eran realmente las relaciones, y eso no es suficiente para saber qué se incluye en las tablas o qué enunciados las filas en un resultado de consulta satisfacer.
Tenga en cuenta que esto es todo lo que necesita para actualizar y consultar una base de datos.
Dadas algunas declaraciones y las situaciones que pueden surgir, se deduce que la base de datos siempre estará en ciertos estados. Le informamos al DBMS sobre eso a través de "restricciones", por lo que puede evitar otros estados y también optimizar la ejecución. Por ejemplo, si siempre es el caso EXISTS Name, Id User (Name, Id, LocId) IMPLIES EXISTS State, City Location (LocId, State, City) es decir que USER PROJECT LocId <= Location PROJECT LocId entonces decimos que hay un " restricción de inclusión "del LocId del usuario a la ubicación. Si también {LocId} es una clave de Location, también hay un FK desde LocId del Usuario hasta Location. Repito, uno no necesita esto para consultar; los estados que violen esto nunca surgirán del uso de las declaraciones, excepto por error.
Usted y otros comentaristas aquí sufren de confusiones comunes que se enseñan como interpretaciones erróneas de los métodos o, lamentablemente, son partes reales de los métodos. Por ejemplo, se usa "relación", lo que significa ciertos tipos de restricciones en las tablas / relaciones en una base de datos. Uno confusamente dice que hay "una" "muchas: 1" "relación" entre los usuarios y las ubicaciones. Lo que esto significa en realidad es que la tabla / relación User PROJECT Id, LocId ie EXISTS Name User (Nombre, Id, LocId) entre usuarios (que son 1: 1 con Id) y ubicaciones (que son 1: 1 con LocIds) tiene la propiedad de ser muchos: 1, es decir, que muchos usuarios pueden estar ubicados en la misma ubicación en algunos estados de bases de datos. Entonces esto se confunde aún más con la existencia de una restricción de inclusión o FK de los usuarios a las ubicaciones. Entonces las personas piensan vagamente que tales cosas "conectan" las tablas, pero restringen las tablas (es decir, la base de datos) y son irrelevantes para las consultas.
Lea sobre NIAM o FCO-IM o el Modelo de roles de objetos que le dirá cómo pensar claramente sobre el diseño. (Los libros de Halpin le dicen cómo mapear desde ORM2 a ER y otros sin deformarse por conceptos erróneos comunes).
Depende de los requisitos de su proyecto (Diseño)
La relación puede ser la siguiente:
* El usuario tiene una ubicación y una ubicación relacionadas con un usuario (relación uno a uno)
* El usuario tiene una ubicación o más y la ubicación está relacionada con un usuario específico (relación de uno a muchos )
* El usuario tiene una ubicación o más y la ubicación está relacionada con más de un usuario (relación de muchos a muchos)