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
ACCOUNT
puede tener muchosENTRIES
Un
ENTRY
puede ser unCREDIT
oDEBIT
- Un
ENTRY
tiene una fecha en la que fue acreditado o debitado - Un
ENTRY
tiene un soloPAYEE
Un
ENTRY
puede ser asociado a unBUDGET CATEGORY
A
CREDIT
tiene una cantidad deENTRY
- A
CREDIT
tiene una descripción deENTRY
- A
CREDIT
se puede programar en el futuro A
CREDIT
puede ser recurrente en frecuencia y / o cantidadA
DEBIT
tiene una cantidad deENTRY
- A
DEBIT
tiene una descripción deENTRY
- A
DEBIT
se puede programar en el futuro A
DEBIT
puede ser recurrente en frecuencia y / o cantidadA
PAYEE
tiene un nombreA
BUDGET
tiene muchosBUDGET CATEGORIES
A
BUDGET
solo se puede asociar a un único mes calendarioA
BUDGET CATEGORY
puede contener muchosENTRIES
- A
BUDGET CATEGORY
tiene un nombre A
BUDGET CATEGORY
tiene unaBUDGET
cantidadA
FORECAST
tiene una fecha de inicio- A
FORECAST
tiene una fecha de finalización - A
FORECAST
tiene un saldo inicial - A
FORECAST
tiene muchosFORECASTED DAYS
A
FORECAST
tiene un soloFORECASTED BUDGET
A
FORECASTED DAY
tiene una sola fecha- A
FORECASTED DAY
puede tener muchosFORECASTED DEBITS
A
FORECASTED DAY
puede tener muchosFORECASTED CREDITS
A
FORECASTED DEBIT
tiene una cantidad- A
FORECASTED DEBIT
tiene una descripción - A
FORECASTED DEBIT
tiene unFORECASTED BUDGET CATEGORY
- A
FORECASTED DEBIT
tiene un soloPAYEE
A
FORECASTED DEBIT
puede ser recurrenteA
FORECASTED CREDIT
tiene una cantidad- A
FORECASTED CREDIT
tiene una descripción - A
FORECASTED CREDIT
tiene unFORECASTED BUDGET CATEGORY
- A
FORECASTED CREDIT
tiene un soloPAYEE
A
FORECASTED CREDIT
puede ser recurrenteA
FORECASTED BUDGET
tiene muchosFORECASTED BUDGET CATEGORIES
A
FORECASTED BUDGET CATEGORY
puede tener muchosPAYEES
A
PAYEE
tiene 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.
- Cada presupuesto puede contener más de 1 categoría de presupuesto. Agregué una
isActive
columna en ambosBudgets
yBudgetCategories
en caso de que quisiera reactivar un presupuesto o categoría de presupuesto diferente. - Separé las transacciones en dos tablas divididas muy parecidas
Debits
y,Credits
como vi, había dos tipos de transacciones. - Para permitir y rastrear transacciones programadas o recurrentes, creé una
ScheduledTransactions
tabla que me permitía tener dos cantidades diferentes, una cantidad esperadaScheduledTransactions
y una cantidad real enDebits
oCredits
.
- 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.
Respuestas:
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.
fuente
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.
fuente