This presentation by Excella Consulting's Shahed Chowdhuri and Sahil Talwar covers EF Code First Migrations and Lean Enterprise Architecture Design.
Including:
- How we use EF Code First Migrations to keep our developers' databases in sync, automatically deploy updates using TeamCity and work with DB Architects who utilize tools like ER/Studio.
- Real world examples to explain how to combat over engineering in an enterprise application through lean startup principles.
This presentation by Excella Consulting's Shahed Chowdhuri and Sahil Talwar covers EF Code First Migrations and Lean Enterprise Architecture Design.
Including:
- How we use EF Code First Migrations to keep our developers' databases in sync, automatically deploy updates using TeamCity and work with DB Architects who utilize tools like ER/Studio.
- Real world examples to explain how to combat over engineering in an enterprise application through lean startup principles.
2. • Es un modelo de datos basado en una percepción del mundo
real que consiste en un conjunto de objetos básicos llamados
entidades y relaciones entre estos objetos. Describe los datos
en los niveles conceptual y de vista.
• El modelo E-R, tiene su implementación grafica en el
Diagrama Entidad-Relación.
• Fue inventado por Peter Chen en los años setenta.
• El propósito de este modelo es simplificar el diseño de bases
de datos a partir de descripciones textuales de los
requerimientos.
3. • Asociación o vinculación entre
dos o más entidades.
• Puede ocurrir entre :
– Dos entidades de un mismo
conjunto de entidades (por
ejemplo, un empleado es
supervisado por su jefe, quien a
su vez es otro empleado).
– Entre entidades de conjuntos
distintos (por ejemplo, un
curso es dictado por un
profesor).
Rombos que representan
conjuntos de relaciones.
4. • Se pueden distinguir tres tipos de relaciones:
1. Relación Uno a Uno: Cuando un registro de
una tabla sólo puede estar relacionado con
un único registro de la otra tabla y viceversa.
• Por ejemplo: tenemos dos tablas una con los
datos de diferentes poblaciones y otra con
una lista de Alcaldes, una población sólo
puede tener un alcalde, y un alcalde lo será
únicamente de una población.
5. 2. Relación Uno a Varios: Cuando un registro de una
tabla (tabla secundaria) sólo puede estar relacionado
con un único registro de la otra tabla (tabla
principal) y un registro de la otra tabla (tabla
principal) puede tener más de un registro relacionado
en la primera tabla (tabla secundaria).
• Por ejemplo: tenemos dos tablas una con los datos de
diferentes poblaciones y otra con los habitantes, una
población puede tener más de un habitante, pero un
habitante pertenecerá (estará empadronado) en una
única población.
6. 3. Relación Varios a Varios: Cuando un registro de una tabla
puede estar relacionado con más de un registro de la otra
tabla y viceversa.
• Por ejemplo: tenemos dos tablas una con los datos de
clientes y otra con los artículos que se venden en la
empresa, una cliente podrá realizar un pedido con varios
artículos, y un artículo podrá ser vendido a más de un
cliente.
• Las relaciones varios a varios se suelen representar
definiendo una tabla intermedia entre las dos tablas.
Siguiendo el ejemplo anterior sería definir una tabla líneas
de pedido relacionada con clientes y con artículos.
7. El proceso de diseño consta de los pasos siguientes:
• Determinar la finalidad de la base de datos
Esto le ayudará a estar preparado para los demás pasos.
• Buscar y organizar la información necesaria
Reúna todos los tipos de información que desee registrar en la base de datos,
como los nombres de productos o los números de pedidos.
• Dividir la información en tablas
Divida los elementos de información en entidades o temas principales, como
Productos o Pedidos. Cada tema pasará a ser una tabla.
• Convertir los elementos de información en columnas
Decida qué información desea almacenar en cada tabla. Cada elemento se
convertirá en un campo y se mostrará como una columna en la tabla. Por ejemplo,
una tabla Empleados podría incluir campos como Apellido y Fecha de contratación.
8. • Especificar claves principales
Elija la clave principal de cada tabla. La clave principal es una columna que se
utiliza para identificar inequívocamente cada fila, como Id. de producto o Id. de
pedido.
• Definir relaciones entre las tablas
Examine cada tabla y decida cómo se relacionan los datos de una tabla con las
demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las
relaciones según sea necesario.
• Ajustar el diseño
Analice el diseño para detectar errores. Cree las tablas y agregue algunos registros
con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las
tablas. Realice los ajustes necesarios en el diseño.
• Aplicar las reglas de normalización
Aplique reglas de normalización de los datos para comprobar si las tablas están
estructuradas correctamente. Realice los ajustes necesarios en las tablas