Quiero almacenar datos de existencias en una base de datos. Podría ser fecha | stock | precio | volumen. Pensé que era una gran tabla para crear y mis datos encajarían perfectamente en una tabla tridimensional con el siguiente eje (fecha, nombre de stock, datos), pero esta no es una base de datos normalizada. ¿Cuál es el mejor formato para mi base de datos?

Answer 1

En mis primeros años, volqué todos estos datos en una sola tabla: [símbolo, fecha, precio, volumen]. La tabla creció a más de 10 millones de filas y el rendimiento comenzó a degradarse (MySQL). Además, quería hacer consultas para fechas específicas, como “SELECCIONAR * de la tabla DONDE fecha = AAAAMMDD” … y de repente, el rendimiento era insoportable, y los índices en (fecha, símbolo) no ayudaron.

Hay archivos de datos binarios de alta dimensión que se supone que ayudan con este problema, pero descubrirá que tienen el mismo rendimiento que una tabla de base de datos indexada y optimizada …

Ninguna solución funcionará mejor.

¿Alguna vez se preguntó por qué los grandes sitios web (Yahoo, Google) solo muestran 5 días de datos de 1 minuto, 1 mes de datos de 5 minutos, algunos años de datos diarios y luego semanalmente? … son muchos datos.

Optimice sus tablas de datos para respaldar sus consultas. Tendrá redundancia, así que automatice el proceso de creación de redundancia y viva con un esquema degradado. Su ciclo de análisis será mucho más rápido.

Ver también: voy a almacenar los precios de las acciones de muchos mercados bursátiles, como el mercado de valores de Nasdaq y de Nueva York, etc. ¿Cuántos datos tendré si mi aplicación se ejecuta durante 3 o 4 años? (más los últimos 10 años como datos históricos) ¿Necesitaré una base de datos no SQL para eso? ¿Una serie de tiempo noSQL quizás?

Answer 2

Al igual que con cualquier ejercicio de modelado de datos físicos, se debe considerar el perfil de los datos y la forma en que se utilizarán.

Cuando se piensa en cómo se usarán los datos con los datos de stock, hay dos cosas importantes en las que pensar.

• Cargando los datos (ETL)
• Consumo de los datos.

Cuando piense en cargar los datos, simplemente agregar nuevas filas de datos de fin de día (EOD) será trivial. Dicho esto, si eso es todo lo que haces, tus datos no serán muy útiles. El truco será cómo gestionar cómo cambian los símbolos de stock con el tiempo mientras se mantienen las relaciones con los datos de EOD. Además, ¿cómo gestiona las reexpresiones o la necesidad de reexpresar los datos cuando se trata de Splits || Merges. Hay algunas otras cosas que surgirán con este dominio que son similares que hacen que los datos ETL de EOD sean interesantes.

Al consumir los datos, uno querrá hacer muchas comparaciones de datos actuales con datos históricos. Probablemente exista la necesidad de calcular previamente las ventanas como funciones. Asegurar que estos atributos derivados puedan usarse en futuros algoritmos tiene mucho sentido. Este tipo de casos de uso querrá un patrón de diseño completamente diferente al que se usará durante ETL

Este tipo de problemas son ideales para una estrategia DWH muy tradicional a pesar de que 10 años de datos son muy pequeños.

Lo que eso significa para mí es cargar todos los datos y mantenerlos actualizados en una estructura 3nf donde puede administrar RI y limpieza de datos. El perfil de datos determinará claramente cómo se debe crear el modelo 3nf. Tener este tipo de dominio de preconsumo estabilizado en un 3nf es valioso. Cargar y mantener datos 3nf es muy limpio.

También será ideal para convertir rápidamente el EOD en un dominio de consumo. Los datos de consumo deben personalizarse según lo necesiten los algoritmos utilizados para generar informes. Tiene sentido que la capa de consumo esté en un esquema de estrella. Los diferentes hechos se crean para el consumo en función de los atributos que necesita para el análisis y sus relaciones con la CANTIDAD y los montos de la actividad comercial, así como con los atributos derivados.

es decir, un hecho puede tener reglas aplicadas para personalizar los datos para algoritmos de volatilidad. Otro hecho puede buscar Stock SPLIT / MERGE o Ratio Algorithms.

Los hechos pueden desaparecer y reconstruirse según sea necesario. Esto probablemente sería más fácil que actualizar cuando cambian los símbolos de stock o se producen divisiones EOD || fusiones.

El dominio 3nf sería persistente.

Answer 3

La normalización es un proceso de organización de los datos en la base de datos para evitar la redundancia de datos, la anomalía de inserción, la anomalía de actualización y la anomalía de eliminación. Analicemos primero las anomalías y luego analizaremos las formas normales con ejemplos.

Para obtener #help visite mi perfil: https://goo.gl/anZ1XM

Para superar estas anomalías necesitamos normalizar los datos. En la siguiente sección discutiremos sobre la normalización.

Normalización

Estas son las formas normales más utilizadas:

• Primera forma normal (1NF)
• Segunda forma normal (2NF)
• Tercera forma normal (3NF)
• Boyce & Codd forma normal (BCNF)

Primera forma normal (1NF)

Según la regla de la primera forma normal, un atributo (columna) de una tabla no puede contener múltiples valores. Debe contener solo valores atómicos.

Segunda forma normal (2NF)

Se dice que una tabla está en 2NF si se cumplen las dos condiciones siguientes:

• La tabla está en 1NF (primera forma normal)
• Ningún atributo no primo depende del subconjunto adecuado de cualquier clave candidata de la tabla.

Un atributo que no forma parte de ninguna clave candidata se conoce como atributo no primo.

Tercera forma normal (3NF)

Se dice que un diseño de tabla está en 3NF si se cumplen las dos condiciones siguientes:

• La mesa debe estar en 2NF
• Se debe eliminar la dependencia funcional transitiva del atributo no principal en cualquier superclave.

Un atributo que no forma parte de ninguna clave candidata se conoce como atributo no primo.

En otras palabras, 3NF puede explicarse de la siguiente manera: una tabla está en 3NF si está en 2NF y para cada dependencia funcional X-> Y se cumple al menos una de las siguientes condiciones:

• X es una súper clave de mesa
• Y es un atributo principal de la tabla

Un atributo que forma parte de una de las claves candidatas se conoce como atributo principal.

Answer 4

Aclaración de Dhia Ben
–
voy a usar el servidor SQL
generalmente son consultas de lectura de datos para el objetivo de análisis
Almacenaré datos históricos de 2003 una vez al día para cada acción
las consultas solicitarán un valor (volumen, precio, etc.) para un stock específico en una fecha específica
muchos usuarios usarán la base de datos pero solo para lectura
–
Siempre que no sea probable que cambie el caso de uso (carga de datos estática, stock_symbol es una clave natural), entonces diría que la tabla única con date | stock_symbol | price | volume es una buena solución. Aunque técnicamente el stock_symbol podría dividirse en su propia tabla de 2 campos con una clave y un símbolo, realmente no está comprando nada al hacerlo, y dividir las fechas en su propia tabla es una sobre normalización casi siempre.

Si, por otro lado, necesitaba almacenar alguna descripción del stock o tenía una expectativa razonable de que el símbolo del stock cambiara, entonces dividirlo en una tabla separada se vuelve más importante para la integridad de los datos.

Tenga en cuenta también que la normalización es un proceso que tiene 2 funciones principales
1. integridad de los datos (cambiar los datos en un solo lugar afecta a todos los lugares donde se necesitan los datos)
2. almacenamiento de datos (almacene los datos solo una vez y use una clave más pequeña para hacer referencia a ellos para reducir el costo de almacenamiento)

Los altos niveles de normalización casi nunca mejoran el rendimiento de lectura. Son necesarios para los momentos en que tiene una base de datos altamente modificable, por lo que la integridad es frágil o cuando el almacenamiento de datos podría ser un problema. No tienes ninguno de estos problemas.

Gracias
Beto

Answer 5

Crearía dos tablas de la siguiente manera:

Tabla de información de existencias
Número de inventario
Stock_name

Tabla Stock_data
Fecha
Número de inventario
Volumen
Precio

Por supuesto, puede generar automáticamente la clave primaria o utilizar la fecha y Stock_code como clave principal.

Stock_code en la segunda tabla será clave clave para la primera tabla

Answer 6

Definirá el stock en una tabla y las transacciones en otra, tal como lo han dicho otros. Cada acción tiene una identificación a la que se hace referencia en la tabla de transacciones. También recomendaría una identificación única para cada transacción.
Para MS SQL Server, ciertamente consideraría índices con múltiples columnas.
Decenas de millones de columnas no serán un problema.

El concepto de cubos es mirarlo, no ingresar datos o almacenar datos en vivo.

Answer 7

Puedo responder con respecto al modelo relacional de Knack. Similar a la respuesta de Bader EX, configuraría dos tablas (u objetos como se definen en Knack).

Objeto 1: Información de stock
Campos: símbolo de stock, nombre

Objeto 2: Datos de stock
Campos: símbolo de stock (conexión del objeto 1 – como una tecla), fecha, precio, volumen

La “conexión” que mencioné crea una relación padre / hijo entre la información de Stock (uno) y el dato de Stock (muchos). Esto también se puede representar gráficamente.

Answer 8

He usado MySQL ejecutándose en un servidor VPS para almacenar datos de existencias al final del día de los mercados estadounidenses y otros datos de análisis. La velocidad de consulta era lenta cuando había otras tablas de unión. Tengo que mantener todos mis datos solo en series de tiempo de 1 año.

Uno o dos años después lo migré al alojamiento en la nube con un procesamiento más rápido y las consultas fueron más rápidas. Eso fue hace unos 3 años.

Ahora, con el potente alojamiento en la nube y la tecnología Big Data, creo que será la mejor solución. Es posible que desee consultar las soluciones de servicios financieros de Google Cloud Platform y la tecnología que utilizaron para Big Data.

Gerente en Singapur hogar, productos y servicios de oficina y Singapur SEO

Answer 9

Sin saber para qué lo necesita, esto hace que sea difícil de responder.
Es como tener madera, clavos, ventanas, puertas. ¿Construyendo una casa? No un Go Kart.
Usted tiene los datos, pero el proceso de toma de decisiones que se necesita y los requisitos que rodean la decisión deben conducir al formato óptimo de los datos de origen.

Answer 10

Asumiré que está haciendo esto para todas las acciones en una bolsa de valores y no para todas las acciones en todo el mundo.

No creo que su mesa vaya a ser tan descomunal, si como leí más abajo solo está ahorrando un precio por acción por día. Siendo realistas, eso es solo un pequeño número de miles de registros por día. Eso realmente no es nada para una base de datos relacional moderna en un servidor adecuado.

Dependiendo de qué otro tipo de datos desea almacenar sobre cada stock, probablemente recomendaría tener dos tablas

Cepo:

• id (int) autoincrementing
• code (char) – código de stock corto
• nombre (varchar) – nombre de stock completo
• potencialmente otros datos de referencia para este stock

Precios:

• id (int) autoincrementing
• stock_id (int) clave externa para el campo de id. de tabla de stocks
• precio (decimal) presumiblemente precio de cierre de stock para ese día
• fecha (fecha) fecha de precio
• volumen (int) volumen diario de existencias

Dependiendo del intercambio, es posible que desee agregar un campo de moneda (char3) a una de las tablas.

Answer 11

Como no hay dependencias funcionales entre sus atributos, su tabla está realmente normalizada.

Sin embargo, le sugiero que almacene la descripción de seguridad en otra tabla y comparta una clave común (security_id) entre ellos.

También le sugiero que agregue un código de convención de precios que se pueda asignar fácilmente más adelante a cualquier combinación como moneda, precio de compra o venta, intercambio de mercado, etc.

F

Answer 12

Telechart, Tradestation y creo que muchos otros softwares le brindan fecha / hora frente a los datos de inventario para cada seguridad en un archivo. Puede escribir un programa Matlab o un programa C o utilizar cualquier DBMS para cargarlos y crear una base de datos tridimensional con Stock Symbol como su clave principal. Solo un pensamiento.