Diseño de base de datos para revisión de pronósticos


8

Estoy tratando de aprender más sobre las bases de datos relacionales y pensé que no hay mejor manera de aprender que hacer algo. Decidí hacer un intento personal de mirar la Contabilidad y previsión del presupuesto personal. He realizado algunas investigaciones hasta el momento y me gustaría obtener una idea de mi diseño de base de datos y normalización actual.

¿Cuáles son sus pensamientos y sugerencias sobre mi diseño de base de datos actual? He incluido información a continuación para ayudarlo mejor a ayudarme :)

Divulgación: Este es un proyecto personal. No para la tarea o para el trabajo.

Hechos empresariales

  • Un banco ACCOUNTpuede tener muchosENTRIES

  • Un ENTRYpuede ser un CREDIToDEBIT

  • Un ENTRYtiene una fecha en la que fue acreditado o debitado
  • Un ENTRYtiene un soloPAYEE
  • Un ENTRYpuede ser asociado a unBUDGET CATEGORY

  • A CREDITtiene una cantidad deENTRY

  • A CREDITtiene una descripción deENTRY
  • A CREDITse puede programar en el futuro
  • A CREDITpuede ser recurrente en frecuencia y / o cantidad

  • A DEBITtiene una cantidad deENTRY

  • A DEBITtiene una descripción deENTRY
  • A DEBITse puede programar en el futuro
  • A DEBITpuede ser recurrente en frecuencia y / o cantidad

  • A PAYEEtiene un nombre

  • A BUDGETtiene muchosBUDGET CATEGORIES

  • A BUDGETsolo se puede asociar a un único mes calendario

  • A BUDGET CATEGORYpuede contener muchosENTRIES

  • A BUDGET CATEGORYtiene un nombre
  • A BUDGET CATEGORYtiene una BUDGETcantidad

  • A FORECASTtiene una fecha de inicio

  • A FORECASTtiene una fecha de finalización
  • A FORECASTtiene un saldo inicial
  • A FORECASTtiene muchosFORECASTED DAYS
  • A FORECASTtiene un soloFORECASTED BUDGET

  • A FORECASTED DAYtiene una sola fecha

  • A FORECASTED DAYpuede tener muchosFORECASTED DEBITS
  • A FORECASTED DAYpuede tener muchosFORECASTED CREDITS

  • A FORECASTED DEBITtiene una cantidad

  • A FORECASTED DEBITtiene una descripción
  • A FORECASTED DEBITtiene unFORECASTED BUDGET CATEGORY
  • A FORECASTED DEBITtiene un soloPAYEE
  • A FORECASTED DEBITpuede ser recurrente

  • A FORECASTED CREDITtiene una cantidad

  • A FORECASTED CREDITtiene una descripción
  • A FORECASTED CREDITtiene unFORECASTED BUDGET CATEGORY
  • A FORECASTED CREDITtiene un soloPAYEE
  • A FORECASTED CREDITpuede ser recurrente

  • A FORECASTED BUDGETtiene muchosFORECASTED BUDGET CATEGORIES

  • A FORECASTED BUDGET CATEGORYpuede tener muchosPAYEES

  • A PAYEEtiene un nombre

Data de muestra

+----------------+----------+------------------+----------------+---------------+--------------+------------------+
| Account Number |   Date   |   Description    |   Payee Name   | Credit Amount | Debit Amount | Budget Category  |
+----------------+----------+------------------+----------------+---------------+--------------+------------------+
|          25178 | 10/01/18 | Payroll          | My Work        | $1000.00      |              | Income           |
|          25178 | 10/02/18 | McRibs for Lunch | McDonalds      |               | $13.12       | Fast Food        |
|          25178 | 10/03/18 | Electric Bill    | FPL            |               | $133.68      | Electric         |
|          25178 | 10/04/18 | Water Bill       | City Water Co. |               | $58.12       | Water and Sewage |
|          25178 | 10/05/18 | Clothes for Work | Target         |               | $65.02       | Clothes          |
|          99875 | 10/28/18 | Bonus Check      | My Work        | $1300.00      |              | Income           |
+----------------+----------+------------------+----------------+---------------+--------------+------------------+

+----------+-------------+--------------+---------------+-----------------+------------------+
| Due Date |    Payee    | Debit Amount | Credit Amount | Budget Category | Re-Occurs On Day |
+----------+-------------+--------------+---------------+-----------------+------------------+
| 10/28/18 | Mortgage Co | $1500.00     |               | Mortgage        |               28 |
| 10/01/18 | My Work     |              | $990.00       | Income          |                1 |
| 10/03/18 | FPL         | $110.00      |               | Electric        |                3 |
+----------+-------------+--------------+---------------+-----------------+------------------+

Diseño de base de datos actual

Pensé que sería útil saber POR QUÉ hice algo para que puedas entender mi lógica y razonamiento.

Revisión4-Pronóstico

  • Cada presupuesto puede contener más de 1 categoría de presupuesto. Agregué una isActivecolumna en ambos Budgetsy BudgetCategoriesen caso de que quisiera reactivar un presupuesto o categoría de presupuesto diferente.
  • Separé las transacciones en dos tablas divididas muy parecidas Debitsy, Creditscomo vi, había dos tipos de transacciones.
  • Para permitir y rastrear transacciones programadas o recurrentes, creé una ScheduledTransactionstabla que me permitía tener dos cantidades diferentes, una cantidad esperada ScheduledTransactionsy una cantidad real en Debitso Credits.

Revisión 4-Main

  • Pensé que cada pronóstico necesitaría una fecha de inicio y finalización, así como un saldo inicial.
  • Sería necesario pronosticar cada día para poder determinar la suma de los débitos y créditos.
  • Creo que podría haber usado las otras tablas y agregar algunas columnas isForecasted y habría funcionado igual. Decidí no seguir esa ruta para desacoplar los dos en caso de que fuera necesario realizar algún cambio, así como si se tratara de una aplicación a gran escala que leyera y escribiera pronósticos grandes en las mismas tablas que las transacciones reales, creo que causaría un registro de problemas de rendimiento.

solo un pensamiento, ¿requiere columnas de metadatos en cada tabla, como cuando se insertó la fila, quién la insertó, cuándo se actualizó por última vez, quién la actualizó, qué proceso, etc.?
Biju jose

Como esto es para uso de desarrollo personal, no necesitaré nada de eso.
Jon H

1
El esquema y las reglas de normalización dependen de cómo elija modelar el problema. Tradicionalmente, tendría tablas separadas para datos reales, presupuestos y pronósticos. Pero podría tenerlos todos en una sola tabla con un atributo o indicador para denotar la diferencia. Lo mismo con DR / CR. Misma tabla pero usa valores +/- para indicar E / S. Una vez que pasa a la contabilidad de doble entrada, necesitará ambos lados de una ecuación para equilibrar y crear cuentas. ¿Vas tan lejos?
Sir Swears-a-lot el

1
Creo que este es un proyecto muy ambicioso para abordar con el propósito de aprender sobre bases de datos. El diseño y la normalización de Db Schema son una cosa, el mantenimiento preciso de registros es otra, la contabilidad y las previsiones son aún más complejas. Cual es tu prioridad?
Sir Swears-a-lot el

@ SirSwears-a-lot Sí, no voy tan lejos. Piense en poder rastrear sus finanzas personales en varios grupos de presupuesto y poder proyectar situaciones simples como ... ¿Qué pasa si recibo el pago de un auto nuevo y me voy de vacaciones 4 meses? ¿Cómo sería mi relación ingreso / deuda en una frecuencia de semana a semana o mes a mes? ¿O qué pasa si cambié mi presupuesto de supermercado de 500 a 600?
Jon H

Respuestas:


2

En términos más generales: COMENZARÍA con una lista de preguntas que quiero responder. Me gusta:

¿A quién le estoy pagando más? ¿Pagué la factura de alcantarillado este mes? ¿Cuáles son mis requisitos de efectivo para este mes? ¿Tendré que salir y matar cosas para comer?

La naturaleza de estas preguntas debe conducir el diseño del esquema.

Dicho esto, este esquema se ve bastante bien.

Estoy de acuerdo con la idea de que los débitos y créditos podrían estar en una sola tabla.


1

Identificaría a los beneficiarios, en términos de presupuesto y tipo de cuenta. Digamos que necesita enumerar o consultar a los beneficiarios. También tendría una columna activa para beneficiarios. Sería bueno saber qué cuenta paga qué presupuesto en el futuro.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.