¿Cómo entender una base de datos que ya está desarrollada?

Question

Mi pregunta puede parecer un poco rara, pero estoy seguro de que la mayoría de ustedes ya pasaron por esta fase.

Actualmente estoy trabajando en un proyecto de migración de base de datos (de FoxPro a SQL Server). La base de datos que se está migrando es amplia y soy nuevo en este proyecto. ¿Hay alguna manera fácil de entender dicha base de datos? ¿Cómo se relacionan las tablas y cómo se modeló? No hay documentación adecuada disponible en este DB.

Creo que entender cómo está construido hace que sea mucho más fácil escribir nuevas consultas/procesos almacenados. Solo curiosidad por saber de cualquier atajo.

Gracias.

Answer 1

Espero que no encuentres muchas respuestas aquí ya que he hecho mi carrera basándome en estos grandes modelos de datos no documentados y tratando de resolverlos. Sino por lo que vale la pena:

• no me gusta el modelador de datos automatizada modelador/electrónica, aunque esto podría ser una opinión personal. Mi preferencia es encontrar una pizarra blanca (o papel) y dibujar su modelo de datos a mano. Si eres un aprendiz cinestésico (aprende con la participación práctica), he encontrado que esta es la mejor manera de familiarizarte con la nueva base de datos ... tan agradable como un sistema automatizado es leer la base de datos, no lo harás. aprende lo que quieras cuando lo dibujas a mano.

• Hay un número limitado de técnicas de modelado de datos, sin embargo, se pueden combinar de muchas maneras. Supongo que con una base de datos más grande como la que tiene aquí, tendrá múltiples programadores que la creen, lo que significa que probablemente verá varias técnicas utilizadas en la misma base de datos. En el pasado, he encontrado un sistema que tenía su información de circuito almacenada como una sola tabla que se autoensamblaba sobre sí misma repetidamente para almacenar la información de un circuito de datos mientras que la sección de información del cliente era un diseño de estrella muy directo ... 2 muy separados estilos de programación, probablemente dos desarrolladores separados. Luego me aventuré en la sección del circuito del teléfono de la aplicación, que reconocí inmediatamente como el mismo estilo (probablemente el mismo programador) que la sección del circuito de datos. Usualmente, los desarrolladores serán asignados a una división lógica que se correlaciona con una sección de su negocio ... observe los patrones en secciones similares.

• La estructura física de la base de datos es solo una sección para entender ... a la izquierda (antes de la base de datos) ¿cómo se generan y cargan los datos en su base de datos (data warehouse?). Entender cuáles son sus datos y cómo se crean es el primer paso para saber lo que está buscando en la base de datos después de que se cargue.

• En el lado opuesto de arriba, después de que los datos estén en la base de datos ... entender cómo se consumen los datos (utilizados por los usuarios) lo ayudará a comprender lo que han estado obteniendo y lo que necesitan de él . Puntos extra si puede tener acceso a las secuencias de comandos utilizadas para generar informes existentes como la declaración de from le ayudará a ver cómo se utilizan las tablas existentes.

• nunca se olvide de entrevistar a sus usuarios ... especialmente si usted puede encontrar uno que estaba alrededor para el despliegue inicial del sistema. Si está diseñado internamente, es probable que estas personas proporcionen algunos de los requisitos iniciales para el sistema y hablar con ellos le dará una idea de lo que las personas que diseñaron el sistema escucharon por primera vez cuando se reunieron los requisitos. La división lógica de su empresa (atención al cliente vs operaciones vs facturación vs etc ...) suele ser la misma división que seguirá su modelo de datos.

• Y por último ... Jugar! Si hay un entorno de desarrollo de calidad o de desarrollo disponible, comience a escribir consultas y vea qué sucede ... modifique su afirmación y vuelva a intentarlo.

Creo que la mayor locura que querrá evitar se centra únicamente en cómo se organizan las tablas. Comprenda los datos que contiene, cómo se generan y cómo se consumen. Comprenda su empresa, cómo está organizada y cómo funciona. La forma en que se almacena (el modelado de datos) es secundario a esta comprensión.

Answer 2

Puede usar SQL Server Management Studio para crear un modelo de relación de entidad, para que pueda ver fácilmente las relaciones entre las tablas de db. Básicamente dentro de su carpeta db en el estudio de administración hay una carpeta llamada "Diagramas de base de datos". Simplemente haga clic derecho y seleccione "Nuevo Diagrama de Base de Datos".

Answer 3

Recientemente realicé el mismo proceso ... Lo que creo que más me ayudó fue crear mi propio diagrama de base de datos. Usé la herramienta gratuita wwwsqldesigner. Parecía bastante fácil, el único problema que tuve fue que no funcionaría en Chrome por alguna razón, pero Firefox funcionó bien. Acabo de poner las tablas que uso mucho, y descubro que con frecuencia vuelvo a consultar cuando necesito hacer algo nuevo.

Si puede usar los diagramas de base de datos generados automáticamente, esa sería una mejor forma de hacerlo, pero personalmente no pude hacer que funcionen (estoy usando el servidor sql).

¡Buena suerte!

Answer 4

¿El antiguo servidor Foxpro coexistirá con el nuevo servidor SQL después de la migración? De lo contrario, debe intentar descifrar el sistema por partes. No es necesario perder tiempo en ningún código estancado y sin usar. ¡Notas y diagramas para obtener una idea general del flujo de datos y comenzar a cavar!

Answer 5

Si voy a una base de datos masiva de SQL Server con cientos de tablas y millones de registros, aquí hay dos consultas que utilizo para ayudarlo a encontrar sentido, encontrar las tablas "principales" y luego reducirlas a tablas específicas y columnas

--Query to show list of tables ordered by number of records in each table 
    SELECT 
     t.NAME AS TableName, 
     SUM(p.rows) AS [RowCount] 
    FROM 
     sys.tables t 
    INNER JOIN  
     sys.indexes i ON t.OBJECT_ID = i.object_id 
    INNER JOIN 
     sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id 
    INNER JOIN 
     sys.columns c on t.object_id = c.object_id 
    WHERE 
     i.index_id <= 1 
    GROUP BY 
     t.NAME, i.object_id, i.index_id, i.name 
    ORDER BY 
     SUM(p.rows) DESC 



--Query to show any columns or table names like what I'm looking for 
SELECT 
    c.name, t.name 
FROM sys.columns c 
    INNER JOIN sys.tables t ON c.object_id = t.object_id 
WHERE c.name LIKE '%#ColumnName%' OR t.name LIKE '%#TableName%' 

Answer 6

Hola la siguiente secuencia de comandos puede ser útil. Si usa esto en cualquier base de datos desarrollada, al menos aprenderá la relación de las tablas.

SELECT 
fk.name 'FK Name', 
tp.name 'Parent table', 
cp.name, cp.column_id, 
tr.name 'Refrenced table', 
cr.name, cr.column_id 
FROM 
    sys.foreign_keys fk 
INNER JOIN 
    sys.tables tp ON fk.parent_object_id = tp.object_id 
INNER JOIN 
    sys.tables tr ON fk.referenced_object_id = tr.object_id 
INNER JOIN 
    sys.foreign_key_columns fkc ON fkc.constraint_object_id = fk.object_id 
INNER JOIN 
    sys.columns cp ON fkc.parent_column_id = cp.column_id AND fkc.parent_object_id = cp.object_id 
INNER JOIN 
    sys.columns cr ON fkc.referenced_column_id = cr.column_id AND fkc.referenced_object_id = cr.object_id 
ORDER BY 
tp.name, cp.column_id 

Answer 7

Existen dos tipos de objetos de datos claramente distintos en Foxpro.
Lo más probable está viendo las tablas de datos libre (DBF, CDX, IDX, archivos de FPT) que no esté incluido dentro de una "base de datos".
Alternativamente FoxPro puede tener una base de datos (un archivo de DBC) que puede contener tablas de datos y los que se pueden celebrada 'en una condición relacionada.

Sin embargo, las tablas de datos de FoxPro normalmente no se relacionan en absoluto hasta que sea necesario por la aplicación a la que vez que se relacionan de manera dinámica basada en una expresión de índice.

Los índices se crean en las tablas de datos utilizando alguna expresión (ejemplo: Fld1 + Fld2 o Account_ID, etc.) que funciona para satisfacer las necesidades de la aplicación.
Estos índices se pueden 'activar' cuando sea necesario para cualquier tabla de datos dada, que ha tenido un índice creado.

Las tablas relacionadas tienen una relación principal/secundaria en la que la tabla secundaria ha activado un índice y la principal se relaciona con ese hijo por valores de sus propios campos que coinciden con la expresión del índice secundario.

La forma en que utiliza los datos una vez que se mueven a un servidor SQL depende de lo que esté utilizando para su aplicación.

Si todavía está utilizando Foxpro para la aplicación, puede consultar el servidor SQL y recuperar los registros en un cursor de memoria (funciona más o menos como una tabla de datos) y si obtiene múltiples cursores de consulta SQL Server, luego puede crear un índice (usando una expresión) y relacionar las tablas según sea necesario.

Si está cambiando la aplicación a algún otro idioma (como quizás VB.net o C++), entonces tendrá que crear sus propias "relaciones" a través de la sintaxis de SQL Query.

Tenga en cuenta que mover las tablas de datos no es una gran cosa.
Pero cambiar el idioma de la aplicación es una GRAN oferta e incluso la forma de abordar cualquier tarea individual deberá manejarse de manera diferente.
Piense que es como traducir un libro del inglés al chino. TODO LO QUE TIENE QUE CAMBIAR.

Si no está seguro y/o no tiene una copia de Foxpro y el código fuente de la aplicación, es mejor considerar la búsqueda de un consultor o bien hacer el trabajo por usted o, al menos, Asistencia/aconsejarle .

Además, tenga en cuenta que si el proyecto es BUSINESS CRITICAL, entonces no debe intentar escatimar en los costos de conversión.

Buena suerte