Puntos a recordar para el diseño de la base de datos Entrevista

En este artículo, vamos a discutir algunas preguntas frecuentes relacionadas con el diseño de bases de datos en una entrevista. Aquí, discutiremos algunos puntos a tener en cuenta al enfrentar una entrevista de diseño de base de datos.  

El diseño de bases de datos es uno de los dominios completos en sí mismo en la industria de las tecnologías de la información. Y cada organización de TI se enfoca en la parte de diseño de la base de datos mientras desarrolla una aplicación o proyecto. En este dominio, puede trabajar específicamente como diseñador de bases de datos y es exigente en la industria de TI. 

Para el rol de diseñador de bases de datos, debe tener un conocimiento sólido de la parte principal fundamental del diseño de la base de datos. Debe tener un sólido conocimiento de cómo diseñar un buen modelo de base de datos para una aplicación según los requisitos especificados de los clientes.

El entrevistador pidió diseñar la base de datos para su uso personal. El mejor enfoque para proceder con este tipo de pregunta es proceder paso a paso y seguir el enfoque de arriba hacia abajo que se mueve desde una visión más amplia a una más estrecha. Uno también podría notar las similitudes entre este enfoque y el enfoque para el diseño orientado a objetos .

1. Manejar la ambigüedad:

Las preguntas de la base de datos a menudo tienen cierta ambigüedad, intencionalmente o no. Antes de continuar con el diseño, uno debe entender exactamente lo que necesita diseñar.

El principal problema planteado fue diseñar un sistema para representar a una agencia de alquiler de apartamentos. Ahora los diseñadores necesitarán saber si esta agencia tiene varias ubicaciones o solo una. Y entonces, el candidato también debe discutir con su entrevistador qué tan general debe ser el diseño. 

Por ejemplo, sería extremadamente raro que una persona alquilara dos apartamentos en el mismo edificio. Pero, ¿eso significa que el diseño no debería poder manejar eso (tal vez, tal vez no)? Algunas condiciones muy raras pueden manejarse mejor a través de una solución alternativa (como duplicar la información de contacto de la persona en la base de datos).

2. Definir los objetos principales:

A continuación, el diseñador debe observar los objetos centrales del sistema que se requiere construir. Cada uno de estos objetos principales normalmente se traduce en una tabla. En este caso, nuestros objetos principales pueden ser Propiedad, Edificio, Apartamento, Inquilino y Gerente.

3. Analizar relaciones:

Una pregunta principal que se planteó fue Delinear los objetos centrales debería darnos una buena idea de lo que deberían ser las tablas. ¿Cómo se relacionan estas tablas entre sí y cómo deben responder? ¿Son de muchos a muchos o de uno a muchos?

Si Edificios tiene una relación de uno a muchos con Apartamentos (un Edificio tiene muchos Apartamentos), esto podría representarse de la siguiente manera.

Apartment ID int
ApartmentAddress varchar(100)
BuildingID int
BuildingID int
BuildingName varchar(100)
BuildingAddress varchar(500)

Nota : 

La tabla Apartamentos se vincula de nuevo a Edificios con una columna BuildingID.

Si una empresa quiere permitir la posibilidad de que una persona alquile más de un apartamento, el diseñador podría querer implementar una relación de muchos a muchos de la siguiente manera.

TenantApartment's ""
TenantID I int
ApartmentID I int
ApartmentID int
ApartmentAddress varchar(500)
BuildingID int
TenantID int
TenantName varchar(100)
TenantAddress varchar(500)

La tabla TenantApartments almacena una relación entre inquilinos y apartamentos.

4. Investigar acciones:

Finalmente, el diseño está listo para completar los detalles en la base de datos. Recorra las acciones comunes que se llevarán a cabo y comprenda cómo almacenar y recuperar los datos relevantes. La estructura final del diseño debe manejar los términos del arrendamiento, mudarse, pagos de alquiler, etc. Cada una de estas acciones requiere nuevas tablas y columnas.