Las bodas suelen ir acompañadas de alegría y celebración, con numerosos invitados, comida, bebidas, música y baile. Pero todo esto no puede suceder sin la debida preparación y coordinación. Echemos un vistazo más de cerca a cómo el modelado de datos puede ayudarnos a organizar mejor una boda para que todo funcione sin problemas.
Antecedentes preliminares
Aunque en su mayoría somos conscientes de cómo es una ceremonia de boda típica, no está de más considerar brevemente algunos aspectos que podrían afectar nuestro modelo de datos.
Compañeros de boda
Aunque la mayoría de las culturas tradicionales tendrán ceremonias entre un hombre y una mujer, los matrimonios entre personas del mismo sexo también tienen lugar en otras sociedades. Nuestro modelo de datos debe diseñarse de tal manera que se adapte a todas las posibilidades.
Escala y complejidad
Las ceremonias de boda varían mucho en tamaño, duración y complejidad. Algunas son ocasiones pequeñas y modestas, pero otras son grandes celebraciones. En Croacia, por ejemplo, puede tener una ceremonia de boda simple en la que una pareja se casa en el ayuntamiento, intercambia sus anillos y votos ante sus invitados y asiste a una cena después de la ceremonia o se va a casa. En otros países, las bodas pueden ser bastante elaboradas:pueden incluir despedidas de soltero/a, negociaciones, cenas, múltiples ceremonias, etc. ¡En algunos casos, estas ceremonias pueden durar varios días y ocurrir en algunos lugares diferentes! Nuevamente, nuestro modelo de datos debe estar preparado para manejar estas situaciones.
Resultado final y gastos
En la mayoría de los casos, la pareja se casa después de la celebración y recibe una factura por todos los gastos (alquiler, alimentos y bebidas, banda, etc.). Pueden decidir contratar a una agencia para que se encargue de todos estos costos por ellos, o pueden optar por manejarlo todo por su cuenta. De cualquier manera, debemos tener en cuenta estas situaciones.
El modelo de datos:descripción general
Nuestro modelo de datos para este artículo consta de cinco secciones:
- Ubicaciones
- Socios, productos y servicios
- Bodas
- Participantes
- Facturas
Discutiremos a fondo cada una de estas áreas en el orden en que se enumeran arriba. Mientras trabajamos en el desarrollo de nuestro modelo de datos, asumiremos el papel de la agencia que organiza la boda.
Sección 1:Ubicaciones
Las Locations La sección presenta tablas universales que se pueden usar en muchos otros modelos de datos. Como señalamos anteriormente, toda la ceremonia de la boda podría ocurrir en un solo lugar, o potencialmente podría abarcar varios lugares. Analicemos las tablas de esta sección con más detalle.
El country tabla almacena información sobre el país en el que se lleva a cabo la boda. En la mayoría de los casos, este país coincidirá con la ubicación de nuestra agencia, pero puede que ese no sea el caso si operamos internacionalmente. Cada país en esta tabla está definido de forma única por su country_name .
A continuación, debemos almacenar la lista de todas las ciudades y/o pueblos donde se organizará la boda. Esta información se almacenará en la city mesa. Para cada ciudad, almacenaremos su nombre y código postal, así como el país en el que se encuentra.
La última tabla en esta área temática es location . Las ubicaciones son más específicas, como ayuntamientos, iglesias, parques, etc. Para cada ubicación, almacenaremos su nombre y una referencia al ID de la ciudad en la que se encuentra. La combinación de estos dos atributos forma la clave única para esta tabla.
Para las ubicaciones, tenga en cuenta que aquí hemos adoptado un enfoque conservador para evitar cubrir los casos inusuales en los que la ceremonia se lleva a cabo en, por ejemplo, un tren o un avión (en cuyo caso, la "ubicación" puede involucrar varias ciudades). Si quisiéramos cubrir estos casos, tendríamos que hacer algunos cambios en nuestro modelo.
Sección 2:Socios, productos y servicios
Antes de pasar a la parte central de nuestro modelo de datos, debemos almacenar la lista de todos los socios con los que trabajamos, así como los productos y servicios que ofrecen. Para lograr esto, usaremos cinco tablas.
En primer lugar, la lista de todos los socios con los que trabajamos se almacena en el partner diccionario. Para cada socio, almacenaremos su partner_code único y partner_name .
Por supuesto, nuestros socios brindarán servicios relacionados con la boda, que pueden incluir catering, organización de bandas, instalación de equipos de audio y video, apoyo para el alquiler y mucho más. Esencialmente, cualquier cosa que se te ocurra puede estar potencialmente relacionada con una boda de alguna manera. Guardaremos esta lista de servicios en el service diccionario. Para cada servicio, almacenaremos:
service_code– un valor que usaremos internamente para denotar de manera única un servicio en particular.service_name– nombre del servicio. Tenga en cuenta que diferentes servicios pueden compartir el mismo nombre. Esto ocurriría si dos de nuestros socios ofrecen el mismo servicio, lo cual es bastante probable. Sería incluso deseable si usaran el mismo nombre para el mismo tipo de servicio porque eso haría mucho más fácil comparar precios para los mismos servicios.description– una descripción textual opcional del servicio.picture– un enlace a la ubicación donde se almacena la imagen del servicio asociado.price– el precio actual de este servicio. Puede contener un valor NULL si el precio no se puede determinar sin evaluar primero varios factores, como cuántas personas planean asistir a la ceremonia.
El provides_service La tabla relaciona a los socios con la lista de servicios que brindan. Para cada combinación única de partner_id y service_id , almacenaremos una descripción textual detallada de la naturaleza del servicio proporcionado por el socio y si el servicio está disponible actualmente.
También necesitamos tablas para almacenar información sobre productos y sus relaciones con los socios. El product la tabla sigue la misma lógica que el service tabla, excepto que, como sugiere el nombre, es específica de los productos. En esta tabla, almacenaremos todos los productos posibles que son esenciales para la mayoría de las ceremonias de boda, como anillos, atuendos, decoraciones, flores, muebles y más.
La última tabla de esta sección es provides_product mesa. Funciona igual que el provides_service tabla, excepto que es específica para productos y no para servicios. Especifica cuál de nuestros socios ofrece el producto en cuestión.
Sección 3:Bodas
Finalmente hemos llegado al corazón de nuestro modelo de datos:las Weddings sección. Contiene cinco tablas nuevas que hacen referencia a las tablas de otras secciones. Tenga en cuenta que también se hará referencia a las tablas propias de esta sección en las próximas partes de nuestro modelo.
En la wedding table, almacenaremos la lista completa de todas las bodas que estamos/estuvimos involucrados en la organización. A cada boda se le asignará su propio wedding_code único. . También almacenaremos las horas de inicio y finalización planificadas para toda la ceremonia, y actualizaremos las horas de inicio y finalización reales cada vez que esta información esté disponible. Además, almacenaremos el budget_planned valor para que al menos tengamos una estimación de cuánto costará todo esto. Todos los demás detalles relacionados con la boda se almacenan en otras áreas del modelo de datos, por lo que esto es todo lo que realmente necesitamos por ahora.
La idea aquí es tratar cada boda como una serie de eventos. Los eventos, a su vez, estarán relacionados con ofertas de productos/servicios deseados, ofertas rechazadas y aceptadas y otros detalles relevantes. Para darte una mejor idea de cómo funciona todo esto, podríamos dividir toda la boda en los siguientes eventos:fase de planificación, despedidas de soltero/a, ceremonia y cena/fiesta posterior. Por supuesto, estos son solo algunos de los eventos de boda más comunes. Todos los eventos de boda se almacenan en la tabla de eventos. Un event tendrá una identificación única.
Cada evento está asociado con una sola boda y estará relacionado con una ubicación o con ninguna. Este último caso surge si el evento es más conceptual , como la fase de planificación (ya que no existe un único lugar donde deba llevarse a cabo). Al igual que con la ceremonia de la boda en sí, un evento tendrá tiempos de inicio y finalización planificados y reales, así como un presupuesto planificado. Tenga en cuenta que hemos mantenido las cosas simples aquí con respecto a las ubicaciones. Si los eventos involucran múltiples ubicaciones, necesitaremos ajustar nuestro modelo de datos.
Continuando, queremos almacenar todos los servicios y productos que están relacionados con un evento. Para ello, utilizaremos tres tablas:status , product_included y service_included .
El status table es un diccionario que realiza un seguimiento de todos los estados relacionados con productos y servicios para un evento en particular. Incluye variables indicadoras que indican si un producto/servicio ha sido ofrecido, aceptado o rechazado. Para cada registro en esta tabla, almacenaremos un status_name único .
Las dos tablas restantes de esta sección, tituladas product_included y service_included , se asemejan entre sí estructural y conceptualmente. Para cada evento, almacenaremos la lista de productos y servicios que se ofrecieron y cambiaremos sus estados si son aceptados o rechazados. Para cada registro en estas dos tablas, almacenaremos los siguientes atributos comunes:
event_id– una referencia al evento relacionado.provides_product_id/provides_service_id– referencias a las tablas con productos/servicios que nuestros socios tienen en oferta.price– precio propuesto para el producto/servicio. Este precio puede diferir del precio estándar que tenemos registrado si proponemos una oferta especial.current_status_id– una referencia alstatusdiccionario que indica si este registro fue ofrecido, aceptado o rechazado.
Sección 4:Participantes
Si está organizando una gran boda, es probable que conozca a la mayoría de los invitados que planean asistir. Por supuesto, los invitados que invite, ya sean sus amigos o familiares, probablemente traigan a otras personas que no conoce personalmente, como sus amigos o colegas. En esta sección almacenaremos la lista completa de invitados que han sido invitados a la boda, así como sus roles.
La person La tabla contiene una lista de todas las personas que forman parte de la boda. Para cada individuo, almacenaremos su person_code único y nombres y apellidos. Por supuesto, podemos agregar más detalles si lo deseamos.
A continuación, definiremos todos los roles posibles que uno podría asumir durante una boda. Estos roles incluyen "invitado", "padrino", "padrino", "dama de honor", "novia", "novio", etc. Para cada función, almacenaremos solo el role_name único en esta tabla. Una persona solo puede asumir un rol para una boda en particular.
A continuación, relacionaremos las bodas con sus participantes. Observe que participate tabla solo contiene referencias a las tablas wedding , person y role . La combinación de wedding_id y person_id sirve como clave alternativa para esta tabla.
La boda constará de varios eventos, pero no todos los participantes estarán involucrados en estos. Por lo tanto, necesitamos almacenar esta información por separado. En el in_event tabla, almacenaremos pares únicos de claves foráneas que hacen referencia a las tablas event y participate . Toda la información adicional se almacenará en los details texto atribuido.
Sección 5:Facturas
¡Ya casi hemos terminado! La última sección de nuestro modelo de datos nos permite realizar un seguimiento de los gastos relacionados con la boda. Emocionante, ¿verdad?
Por lo general, generaremos una invoice por boda, pero también podríamos generar más si lo necesitáramos. Con suerte, la cantidad total que facturamos a la pareja se acercará mucho a nuestro presupuesto planificado, pero puede que no siempre sea así. Para cada factura, almacenaremos la siguiente información:
wedding_id– una referencia a la boda para la que se emitió la factura.time_created– la marca de tiempo de cuando se generó la factura.due_date– la fecha en la que se debe pagar la factura.invoice_amount– el monto total que se debe pagar.payment_time– la marca de tiempo de cuando se emitió realmente el pago. Por supuesto, este atributo contendrá un valor de NULL hasta que se realice el pago.paid– una bandera que indica si la factura fue pagada. Este atributo se establecerá en "Verdadero" tan pronto como elpayment_timeestá actualizado.
La última tabla de nuestro modelo se refiere a los artículos facturados en sí. Los almacenaremos en el invoice_item mesa. Para cada registro, almacenaremos los siguientes detalles:
item_name– nuestro nombre elegido para el elemento específico.item_price– el precio relacionado con ese artículo específico.invoice_id– el id de la factura relacionada.service_included_id– la identificación del servicio con el que está relacionado el elemento de la factura. Este atributo podría establecerse en NULL si el artículo en cuestión no está realmente relacionado con ningún servicio o si es simplemente un cargo adicional que hemos aplicado a la factura.product_included_id– el id del producto con el que está relacionado el artículo de la factura. Este atributo podría establecerse en NULL si el artículo en cuestión no está realmente relacionado con ningún producto o si es simplemente un cargo adicional que hemos aplicado a la factura.
Resumen
¡Eso lo resume todo para este modelo de datos! Una vez más, vemos cuán útil es el modelado de datos para organizar la información de una empresa.
Como notamos, hay muchas cosas que omitimos de nuestro modelo de datos en aras de la simplicidad. Por ejemplo, nuestro modelo idealmente debería rastrear historiales de ofertas, detalles financieros y más.
Háganos saber a continuación si tiene alguna sugerencia. ¡Nos encantaría escuchar tu opinión!
