Diseño De La Base De Datos Del Sistema De Trading

Bienvenido al Hogar del Sistema de Negociación de Java Abierto El Sistema de Negociación de Java Abierto (OJTS) está destinado a ser una infraestructura común para desarrollar sistemas de negociación de valores. Consta de cuatro partes: la recopilación de datos brutos a través de Internet, el reconocimiento de señales comerciales, un módulo de visualización y módulos para conectarse a las interfaces programáticas de plataformas de trading como bancos. El objetivo de los proyectos es proporcionar una infraestructura común autónoma Java (independiente de la plataforma) para los desarrolladores de sistemas comerciales. Algunos de los aspectos que deben abordarse son proporcionar un esquema de base de datos compatible con SQL92 para almacenar datos financieros, interfaces Java comunes para intercambiar datos entre diferentes módulos, visualización de datos financieros crudos y señales comerciales y varios otros aspectos comunes necesarios para crear Un sistema comercial final. Debido a mi trabajo ya mi familia no encuentro el tiempo de mejorar OJTS por más tiempo. Sigo actualizando la sección de enlaces a continuación que le guiará a más activos proyectos de código abierto de Java en esa área, sin embargo. De hecho, como consecuencia de mi interés en la dinámica de los mercados de valores comencé un viaje en los detalles más profundos de la economía nacional con el fin de comprender los tipos de cambio de divisas. Este tema finalmente me lleva a un estudio más profundo del dinero en sí mismo como la unidad métrica que utilizamos en la economía para medir el valor, el éxito o la utilidad. Este tema resultó ser extremadamente interesante, pero al mismo tiempo fue muy difícil encontrar información sobre cómo funciona nuestro sistema monetario. Vaya y pregúntele a la gente de dónde viene el dinero, quién lo crea y qué determina su valor. Usted notará que incluso las personas que tienen un título de maestría o doctorado. En economía no conocerá estos detalles. Oh, sí, ellos responderán en algunos términos crípticos técnicos, pero no serán capaces de dibujar un diagrama simple que describa el proceso. Se dice que H. G. Wells ha dicho: Escribir de moneda es reconocido generalmente como una práctica objetable, de hecho casi indecente. Los editores implorarán al escritor casi con lágrimas de no escribir sobre el dinero, no porque sea un tema poco interesante, sino porque siempre ha sido profundamente inquietante. Sugiero a cualquier persona que viva en una sociedad democrática que lea sobre este tema. Afecta a nuestras vidas todos los días en una medida que no puede ser exagerado En mi opinión, cada ciudadano de un país democrático en ese mundo debe saber de dónde viene nuestro dinero. Lo más probable es que viniste a este sitio web para buscar herramientas que te ayuden a aumentar tu riqueza monetaria. Para entender el dinero de la unidad métrica (no importa si dólar o euro) será un ingrediente importante en su juego de herramientas para hacer dinero. Si usted tiene poco tiempo y sólo puede permitirse el lujo de leer un solo libro sobre ese tema, entonces le sugiero que lea la riqueza, la riqueza virtual y la deuda por Frederick Soddy. Pude comprar una copia usada a través de Amazon para 23.48, pero existe también una versión en línea. Necesitará el plugin DjVu para leerlo. Este libro fue publicado originalmente en 1929, pero todavía describe los hechos reales muy bien. Incluso si no estoy de acuerdo con todas las conclusiones de Frederick Soddy su trabajo es agradablemente provocado y le llevará a hacer las preguntas correctas. Anunció la suspensión del desarrollo activo y agregó referencias a información sobre nuestros sistemas monetarios (Dólar / Euro). Se agregó una sección de enlaces a otros interesantes proyectos del sistema de comercio java. Estoy investigando sobre cómo hacer que OJTS sea más compatible con otros esfuerzos del sistema de negociación de java. Proyecto de Documentación del Sistema de Inversión y Comercio que se encuentra en ITSdoc. org. Hay un nuevo wiki disponible en ITSdoc. org centrado en la distribución del conocimiento en el ámbito de los sistemas de inversión y comercio. La idea detrás de ITSdoc. org es tener una plataforma de colaboración similar a wikipedia ayudando a la comunidad a compartir conocimientos. OpenJavaTradingSystem v0.13 publicado. Ayer publiqué la versión 0.13 de la biblioteca OpenJavaTradingSystem. Entre las nuevas características se encuentran: Recuperación de datos para acciones, fondos y monedas de OnVista. Implementación del manejo de monedas y conversiones. Las carteras se implementan y se puede trabajar con Carteras de la misma manera que con elementos de papel de seguridad individuales. Se agregó un marco general para aplicar algoritmos a las series de tiempo de la bolsa. Se ha cambiado desde el shell interactivo SISC / Scheme a ABCL / CommonLisp más su editor llamado J. Se agregó un mecanismo general de caché de datos para almacenar en caché los datos que ya se habían recuperado en la web en el sistema de archivos. Además muchas más mejoras menores Si estás interesado en esta nueva versión debes comenzar en la sección quickstart / screenshot. El manual aún no se ha actualizado, pero puede proporcionarle información valiosa si desea utilizar la biblioteca de su proyecto. La documentación debe ser actualizada pronto. Actualmente no hay mucho desarrollo hecho, porque estoy actualizando mi conocimiento sobre las redes bayesianas. Vea por ejemplo la lista de libros en mi sitio web. Dos proyectos muy interesantes a este respecto son WEKA y BNJ. Pronto seguiré desarrollando y comenzaré a integrar la primera inteligencia en el sistema. Hoy puse el primer lanzamiento en la sección de archivos del área de descarga de sourceforge. Además actualizé el manual para documentar el uso interactivo del proyecto a través de la capa SISC Scheme. Para el impaciente aquí es un quickstart / captura de pantalla de la sección para que te vayas. Documentos que describen los aspectos internos del proyecto. Documentación de los objetos de datos y la interfaz de Java gtgtHTML gtgtPDF Documentación de uso gtgtHTML gtgtPDF Proyecto de documentación del sistema de inversión y comercio gtgtITSdoc. org T ecnología Bloques de construcción de terceros utilizados en este proyecto HSQL Database Engine (licencia: hsqldblic. txt) HSQLDB es el motor de base de datos incluido con el Proyecto para que pueda comenzar inmediatamente a utilizar el OJTS sin instalar una base de datos de terceros. Pero si va a utilizar otra base de datos compatible con SQL92, esta es una opción de configuración. Castor (Licencia: La licencia de Exolab) Castor es un marco de vinculación de datos Open Source para Javatm. Es el camino más corto entre objetos Java, documentos XML y tablas relacionales. Castor proporciona compatibilidad entre Java y XML, persistencia de Java a SQL y más. Castor Doclet (Licencia: GNU LGPL v2.1) Doclet Java para generar tanto mapas como archivos DDL para Castor JDO y Castor XML. TestMaker (licencia: Licencia de Open Source de TestMaker) Desde el proyecto TestMaker sólo se utiliza la implementación de los protocolos como HTTP o HTTPS para recopilar datos desde la web. JCookie (licencia: GNU LGPL v2.1) La biblioteca jCookie es necesaria para que las bibliotecas de TestMaker funcionen. Htmlparser (licencia: GNU LGPL v2.1) La biblioteca htmlparser se utiliza para extraer los datos de los recursos web. ABCL / CommonLisp (Licencia: GNU GPL v2) ABCL (Armed Bear Common Lisp) se utiliza para implementar el corazón algorítmico del proyecto en el lenguaje de programación ANSI Common Lisp. JFreeChart (licencia: GNU LGPL v2.1) JFreeChart se utiliza para la visualización de datos financieros como gráficos. JSci (licencia: GNU LGPL v2.1) JSci - Una API científica para Java. Joda Time (licencia: Licencia OpenSource creada en casa) Joda Time reemplaza las clases originales de JDK Date and Time. Enlaces a otros proyectos El grupo de JavaTraders de Google puede ser la mejor entrada para que usted pueda encontrar otros sistemas y herramientas de comercio basados ​​en Java. L icense Condiciones de uso El código del proyecto está licenciado bajo los términos de la LGPL y toda la documentación que usted encuentra en este proyecto está licenciada bajo los términos de la FDL. Algorithmic Trading System Architecture Anteriormente en este blog he escrito sobre el conceptual Arquitectura de un sistema de negociación algorítmica inteligente así como los requisitos funcionales y no funcionales de un sistema de trading algorítmico de producción. Desde entonces he diseñado una arquitectura de sistema que creo que podría satisfacer los requisitos arquitectónicos. En este post describiré la arquitectura siguiendo las directrices de los estándares ISO / IEC / IEEE 42010 y el estándar de descripción de arquitectura de ingeniería de software. De acuerdo con esta norma, una descripción de la arquitectura debe: • Contener múltiples vistas estandarizadas de arquitectura (por ejemplo, en UML) y • Mantener la trazabilidad entre las decisiones de diseño y los requisitos arquitectónicos Definición de la arquitectura de software Todavía no hay consenso sobre lo que es una arquitectura de sistemas. En el contexto de este artículo, se define como la infraestructura dentro de la cual se pueden especificar, desplegar y ejecutar componentes de aplicación que satisfacen requisitos funcionales. Los requisitos funcionales son las funciones esperadas del sistema y sus componentes. Los requisitos no funcionales son medidas a través de las cuales se puede medir la calidad del sistema. Un sistema que satisface plenamente sus requisitos funcionales puede todavía no satisfacer las expectativas si los requisitos no funcionales se dejan insatisfechos. Para ilustrar este concepto, considere el siguiente escenario: un sistema de negociación algorítmico que acaba de adquirir / construye hace excelentes decisiones comerciales, pero es completamente inoperable con las organizaciones de gestión de riesgos y sistemas de contabilidad. Este sistema satisface sus expectativas Arquitectura Conceptual Una visión conceptual describe conceptos y mecanismos de alto nivel que existen en el sistema en el nivel más alto de granularidad. A este nivel, el sistema de comercio algorítmico sigue una arquitectura impulsada por eventos (EDA) dividida en cuatro capas, y dos aspectos arquitectónicos. Para cada capa y aspecto se utilizan arquitecturas y patrones de referencia. Los patrones arquitectónicos son estructuras probadas y genéricas para lograr requisitos específicos. Los aspectos arquitectónicos son preocupaciones transversales que abarcan múltiples componentes. Arquitectura impulsada por eventos: una arquitectura que produce, detecta, consume y reacciona ante eventos. Los eventos incluyen movimientos del mercado en tiempo real, eventos o tendencias complejas y eventos comerciales, p. Presentar una orden. Este diagrama ilustra la arquitectura conceptual del sistema de comercio algorítmico. Arquitectura de referencia Para utilizar una analogía, una arquitectura de referencia es similar a los planos para una pared portante. Esta impresión azul puede ser reutilizada para diseños de edificios múltiples, independientemente de qué edificio se está construyendo, ya que satisface un conjunto de requisitos comunes. De manera similar, una arquitectura de referencia define una plantilla que contiene estructuras genéricas y mecanismos que pueden usarse para construir una arquitectura de software concreta que satisface requisitos específicos. La arquitectura para el sistema de comercio algorítmico utiliza una arquitectura basada en el espacio (SBA) y un controlador de vista de modelo (MVC) como referencias. También se utilizan buenas prácticas, como el almacén de datos operativos (ODS), el patrón de transformación y carga de extracciones (ETL) y un almacén de datos (DW). Controlador de vista de modelo: un patrón que separa la representación de la información de la interacción del usuario con ella. Arquitectura basada en el espacio: especifica una infraestructura en la que las unidades de procesamiento ligeramente acopladas interactúan entre sí a través de una memoria asociativa compartida llamada espacio (se muestra a continuación). Vista estructural La vista estructural de una arquitectura muestra los componentes y subcomponentes del sistema de negociación algorítmica. También muestra cómo se implementan estos componentes en la infraestructura física. Los diagramas UML utilizados en esta vista incluyen diagramas de componentes y diagramas de implementación. A continuación se muestra la galería de los diagramas de despliegue del sistema de negociación algorítmica global y las unidades de procesamiento en la arquitectura de referencia SBA, así como diagramas de componentes relacionados para cada una de las capas. Tácticas arquitectónicas Según el instituto de ingeniería de software una táctica arquitectónica es un medio de satisfacer un requisito de calidad mediante la manipulación de algunos aspectos de un modelo de atributos de calidad a través de decisiones de diseño arquitectónico. Un ejemplo sencillo utilizado en la arquitectura del sistema de negociación algorítmica es la manipulación de un almacén de datos operativos (ODS) con un componente de consulta continua. Este componente analizaría continuamente las ODS para identificar y extraer eventos complejos. Las siguientes tácticas se utilizan en la arquitectura: El patrón disruptor en el evento y las colas de orden Memoria compartida para el evento y las colas de orden Lenguaje de consulta continua (CQL) en el ODS Filtrado de datos con el patrón de diseño del filtro en los datos entrantes Algoritmos de evitación de congestión en todos (AQM) y notificación de congestión explícita Recursos de computación de productos básicos con capacidad de actualización (escalable) Redundancia activa para todos los puntos de falla individuales Indexación y estructuras de persistencia optimizadas en el ODS Programar scripts regulares de copia de seguridad y limpieza de datos ODS Historial de transacciones en todas las bases de datos Checksums para todos los pedidos para detectar fallos Anotar eventos con marcas de tiempo para omitir eventos antiguos Reglas de validación de orden, por ejemplo Cantidades máximas de comercio Componentes automatizados de comerciantes utilizan una base de datos en memoria para el análisis Autenticación de dos etapas para interfaces de usuario que se conectan a los ATs Cifrado en interfaces de usuario y conexiones a los ATs Patrón de diseño de observador para MVC para gestionar vistas La lista anterior son sólo unos pocos diseño Decisiones que identifiqué durante el diseño de la arquitectura. No es una lista completa de tácticas. A medida que se está desarrollando el sistema, se deben emplear tácticas adicionales a través de múltiples niveles de granularidad para satisfacer requisitos funcionales y no funcionales. A continuación se muestran tres diagramas que describen el patrón de diseño del disruptor, el patrón de diseño del filtro y el componente de consulta continua. Vista de Comportamiento Esta vista de una arquitectura muestra cómo los componentes y las capas deben interactuar entre sí. Esto es útil cuando se crean escenarios para probar diseños de arquitectura y para entender el sistema de extremo a extremo. Esta vista consiste en diagramas de secuencia y diagramas de actividad. Los diagramas de actividad que muestran el proceso interno de los sistemas de negociación algorítmica y cómo se supone que los comerciantes interactúan con el sistema de comercio algorítmico se muestran a continuación. Tecnologías y marcos El paso final en el diseño de una arquitectura de software es identificar posibles tecnologías y marcos que podrían ser utilizados para realizar la arquitectura. Como principio general es mejor aprovechar las tecnologías existentes, siempre que satisfagan adecuadamente los requisitos tanto funcionales como no funcionales. Un marco es una arquitectura de referencia realizada, p. JBoss es un framework que realiza la arquitectura de referencia JEE. Las siguientes tecnologías y marcos son interesantes y deben ser considerados al implementar un sistema de trading algorítmico: CUDA - NVidia tiene una serie de productos que soportan el modelado de finanzas computacionales de alto rendimiento. Uno puede lograr hasta 50x mejoras de rendimiento en la ejecución de simulaciones de Monte Carlo en la GPU en lugar de la CPU. Apache River - River es un kit de herramientas usado para desarrollar sistemas distribuidos. Se ha utilizado como un marco para la construcción de aplicaciones basadas en el patrón SBA Apache Hadoop - en el caso de que el registro generalizado es un requisito, entonces el uso de Hadoop ofrece una solución interesante para el problema de los grandes datos. Hadoop se puede implementar en un entorno de clúster que admita tecnologías CUDA. AlgoTrader - una plataforma de trading algorítmica de código abierto. AlgoTrader podría potencialmente ser desplegado en el lugar de los componentes automatizados del comerciante. FIX Engine - una aplicación independiente que admite los protocolos de intercambio de información financiera (FIX) incluyendo FIX, FAST y FIXatdl. Aunque no es una tecnología o un marco, los componentes deben ser construidos con una interfaz de programación de aplicaciones (API) para mejorar la interoperabilidad del sistema y sus componentes. Conclusión La arquitectura propuesta ha sido diseñada para satisfacer requisitos muy genéricos identificados para los sistemas de negociación algorítmica. En general, los sistemas de negociación algorítmica se complican por tres factores que varían con cada implementación: Dependencias de la empresa externa y sistemas de intercambio Desafiar los requisitos no funcionales y Evolucionar restricciones arquitectónicas Por lo tanto, la arquitectura de software propuesta debe adaptarse caso por caso para Para satisfacer requisitos organizativos y normativos específicos, así como para superar las limitaciones regionales. La arquitectura del sistema de trading algorítmico debe ser visto como un punto de referencia para individuos y organizaciones que desean diseñar sus propios sistemas de trading algorítmicos. Para obtener una copia completa y las fuentes utilizadas, descargue una copia de mi informe. Gracias. TagsView la solución paso a paso para: Diseño de bases de datos para un sistema de comercio de valores Datos Esta pregunta fue respondida el 03 de junio de 2010. Ver el diseño de base de datos de respuesta para un sistema de comercio de valores Requisitos de datos: La negociación de acciones y opciones de las empresas que cotizan en bolsa y tiene los siguientes requisitos de datos: Una empresa está determinada exclusivamente por su nombre, al tiempo que también tiene una dirección de la sede y una fecha establecida. Dirección es un atributo compuesto, que los componentes número de la calle, número de apartamento, ciudad, calle y código postal. Algunas empresas han cotizado públicamente acciones comunes, y se denominan empresas públicas. Cada empresa pública tiene sólo una de estas acciones, cada acción tiene un código de acciones único y el número especificado de acciones. Cada acción cotiza en uno o más intercambios, pero el número de intercambios comerciales no puede exceder 9. Un intercambio está determinado únicamente por su nombre. Hay un símbolo de acciones asociado con una acción, que se utiliza para intercambios en un intercambio. El mismo stock puede tener símbolos diferentes en diferentes intercambios. Una opción en un símbolo de acciones es un valor que está determinado exclusivamente por su tipo, símbolo de acciones, precio de ejercicio y fecha de vencimiento. Una opción cotiza en el mismo intercambio que su símbolo común. El tipo de una opción es un put o una llamada. No puede ser ambos, y no puede ser otra cosa. El último precio de negociación y el volumen diario actual de cada símbolo y opción deben registrarse. Las acciones y opciones son propiedad y son negociadas por los comerciantes. Un comerciante tiene un nombre y un identificador de impuestos. El identificador de impuestos determina de manera única al comerciante. El valor de id de impuestos es entre 000001 y 900000. Los comerciantes no comercian directamente, sino a través de corretajes. Una correduría está determinada únicamente por su nombre y estado. Cada corredora se ocupa de uno o más intercambios y paga una cuota fija anual a cada intercambio con el que trata. El honorario podría ser diferente para cada par de corretaje / intercambio. Un comerciante posee al menos una cuenta con al menos una correduría. Puede tener más de una cuenta con la misma correduría y tratar con más de una correduría. Una cuenta está determinada únicamente por la correduría y el número de cuenta. Una correduría puede no tener cuentas. Cada cuenta tiene exactamente un propietario. Las cuentas tienen valores y efectivo. Tenga en cuenta que una acción comprada en un intercambio podría ser vendida en otro, por lo que son las acciones, no los símbolos, que se celebran. No olvide incluir opciones en las cuentas. Los operadores colocan órdenes comerciales a través de sus corretajes. Una orden especifica la cuenta, exactamente un símbolo u opción para negociar, pujar (comprar) o pedir (vender), número de acciones a negociar y la caducidad del pedido. Hay dos tipos de órdenes: mercado y límite. Una orden limitada tiene el precio límite además de las propiedades mencionadas. El corredor y la identificación de la orden determinan únicamente el orden. Una transacción se realiza en el cumplimiento (posiblemente parcial) de dos órdenes. Cada transacción contiene la siguiente información: exactamente una orden de puja, exactamente una orden de solicitud, número de acciones, precio de transacción, comisiones pagadas por el comprador y el vendedor a sus corretajes, y la marca de tiempo. El número de transacción y de transacción determina de forma exclusiva la transacción. Tenga en cuenta que un pedido podría ser llenado por varias transacciones. Las acciones y opciones se negocian si sus pedidos se cumplen con algunas transacciones. Análisis de Requisitos de la Parte 1 1. Identificar las principales entidades de este sistema de negociación de valores. 2. ¿Puede pensar en otras entidades distintas a la descrita en los requisitos de datos que se agregarán al sistema de negociación de valores 3. ¿Es la capacidad de modelar las relaciones supertipo / subtipo que puedan ser importantes en ese entorno? ¿Puede usted pensar en 4 reglas más (que no sea la explícitamente descrita anteriormente) que es probable que se utilizan en un sistema de comercio de valores Agregue sus reglas a los requisitos de datos que se implementarán. 5. Justificar el uso de un DBMS relacional como Oracle o SQL Server para este sistema. Parte 2- Diseño conceptual 6- Dibuje un EERD para representar con precisión este conjunto de requisitos. Este será su diseño conceptual. Especifique claramente cualquier suposición que esté haciendo. Puede utilizar cualquier herramienta (software) para dibujar el EERD. Parte 3 Diseño Lógico 7- Se ha decidido utilizar un DBMS relacional para implementar la base de datos. Realice los pasos siguientes. a. Convierta su modelo conceptual (Parte 2) en un modelo lógico que se puede implementar en un DBMS relacional como Oracle. Durante este proceso se reemplazan las relaciones M-N y los atributos de valores múltiples con construcciones que se pueden implementar en el DBMS relacional. Dibuje EERD para el modelo lógico después de sus modificaciones. Siéntase libre de cambiar su modelo conceptual si es necesario. segundo. Convierta el EERD (elemento a) en un diseño de base de datos. Documente su diseño en formato de esquema de base de datos. Parte 4 Normalización. Ahora, usted está listo para su implementación. Utilice convenciones de nomenclatura apropiadas para todas sus tablas y atributos. Normalize todas sus tablas a la tercera forma normal. Realice los cambios necesarios en el EERD de la Parte 2b. Explique por qué estos cambios deben hacerse. 8 - Dibuje un diagrama de dependencia para cada tabla de la Fase III a. 9 - Actualizar diccionario de datos de entrega anterior (parte 3 b.) Para agregar tipo de datos para cada atributo además de especificar si es clave primaria, clave extranjera, se permite NULL o su valor es ÚNICO. Parte 4 Implementación. 10 - Escribir DDL instrucciones SQL para crear bases de datos, tablas y todas las demás estructuras. Las claves primarias y claves foráneas deben estar definidas apropiadamente. No se requieren las limitaciones cuantitativas de la relación entre las entidades, que deben describirse en el diagrama EERD. 11- Utilice la sentencia Create View para crear las siguientes vistas: i. Símbolo de acciones: Esta vista devuelve el nombre de la empresa, la fecha de establecimiento de la empresa, el código de inventario, el número de acciones y los nombres de Exchange de todos los símbolos de acciones. Ii. Alta seguridad: Esta vista devuelve el código de acciones, el último precio de negociación y el volumen diario actual de cada símbolo y opción cuyo último precio de cotización es superior a 100. iii. Good-Trader: Esta vista devuelve todos los Oficios que tienen al menos 3 cuentas de al menos 2 corretajes. Iv. Stock-Traded: Esta vista devuelve el nombre de la empresa, el código de acciones y el número de acciones se ha negociado. V. Popular-Trader: Esta vista devuelve aquellos comerciantes que han negociado acciones más de 1 de todas las acciones negociadas. 12 - Proporcionar sentencias SQL para las siguientes consultas. Siéntase libre de usar cualquiera de las vistas que ha creado en la parte (e): vi. Para cada lista de empresas públicas el número de intercambios en los que cotiza sus acciones. Vii. Encuentre todos los Corretajes que no tienen ninguna cuenta. Viii. Enumerar todos los intercambios que tengan acciones de la empresa pública establecida antes del 01 de enero de 1980. ix. Encuentre cada comerciante que tenga exactamente una cuenta. x. Encuentre todas las Órdenes que hayan sido cumplidas por al menos 2 transacciones. Xi. Enumere todas las empresas en las que el número de acciones que cotizan exceda su número total de acciones. Xii. Enumere toda la cuenta de esos Popular-Traders. Xiii. Enumere todas las existencias que han sido colocadas por Good-Traders. Xiv. Enumere todas las transacciones que cumplieron plenamente sus dos órdenes. Xv. Enumere todas las cuentas que han sido puestas en orden de límite. Se adjunta una versión más fácil de ver del documento. Realmente aprecio la ayuda con este monstruo de una asignación. Requisitos de datos: El sistema de comercio de acciones es un sistema automatizado para el comercio de acciones y opciones de las empresas que cotizan en bolsa y tiene los siguientes requisitos de datos: Una empresa está determinada únicamente por su nombre, mientras que Teniendo también domicilio social y fecha establecida. Dirección es un atributo compuesto, que los componentes número de la calle, número de apartamento, ciudad, calle y código postal. Algunas empresas han cotizado públicamente acciones comunes, y se denominan empresas públicas. Cada empresa pública tiene sólo una de estas acciones, cada acción tiene un código de acciones único y el número especificado de acciones. Cada acción cotiza en uno o más intercambios, pero el número de intercambios comerciales no puede exceder 9. Un intercambio está determinado únicamente por su nombre. Hay un símbolo de acciones asociado con una acción, que se utiliza para intercambios en un intercambio. El mismo stock puede tener símbolos diferentes en diferentes intercambios. Una opción en un símbolo de acciones es un valor que está determinado exclusivamente por su tipo, símbolo de acciones, precio de ejercicio y fecha de vencimiento. Una opción cotiza en el mismo intercambio que su símbolo común. El tipo de una opción es un put o una llamada. No puede ser ambos, y no puede ser otra cosa. El último precio de negociación y el volumen diario actual de cada símbolo y opción deben registrarse. Las acciones y opciones son propiedad y son negociadas por los comerciantes. Un comerciante tiene un nombre y un identificador de impuestos. El identificador de impuestos determina de manera única al comerciante. El valor de id de impuestos es entre 000001 y 900000. Los comerciantes no comercian directamente, sino a través de corretajes. Una correduría está determinada únicamente por su nombre y estado. Cada corredora se ocupa de uno o más intercambios y paga una cuota fija anual a cada intercambio con el que trata. El honorario podría ser diferente para cada par de corretaje / intercambio. Un comerciante posee al menos una cuenta con al menos una correduría. Puede tener más de una cuenta con la misma correduría y tratar con más de una correduría. Una cuenta está determinada únicamente por la correduría y el número de cuenta. Una correduría puede no tener cuentas. Cada cuenta tiene exactamente un propietario. Las cuentas tienen valores y efectivo. Tenga en cuenta que una acción comprada en un intercambio podría ser vendida en otro, por lo que son las acciones, no los símbolos, que se celebran. No olvide incluir opciones en las cuentas. Los operadores colocan órdenes comerciales a través de sus corretajes. Una orden especifica la cuenta, exactamente un símbolo u opción para negociar, pujar (comprar) o pedir (vender), número de acciones a negociar y la caducidad del pedido. Hay dos tipos de órdenes: mercado y límite. Una orden limitada tiene el precio límite además de las 1 propiedades mencionadas. El corredor y la identificación de la orden determinan únicamente el orden. Una transacción se realiza en el cumplimiento (posiblemente parcial) de dos órdenes. Cada transacción contiene la siguiente información: exactamente una orden de puja, exactamente una orden de solicitud, número de acciones, precio de transacción, comisiones pagadas por el comprador y el vendedor a sus corretajes, y la marca de tiempo. El número de transacción y de transacción determina de forma exclusiva la transacción. Tenga en cuenta que un pedido podría ser llenado por varias transacciones. Las acciones y opciones se negocian si sus pedidos se cumplen con algunas transacciones. Análisis de Requisitos de la Parte 1 1. Identificar las principales entidades de este sistema de negociación de valores. 2. ¿Puede pensar en otras entidades distintas a la descrita en los requisitos de datos que se agregarán al sistema de negociación de valores 3. ¿Es la capacidad de modelar las relaciones supertipo / subtipo que puedan ser importantes en ese entorno? ¿Puede usted pensar en 4 reglas más (que no sea la explícitamente descrita anteriormente) que es probable que se utilizan en un sistema de comercio de valores Agregue sus reglas a los requisitos de datos que se implementarán. 5. Justificar el uso de un DBMS relacional como Oracle o SQL Server para este sistema. Parte 2- Diseño conceptual 6- Dibuje un EERD para representar con precisión este conjunto de requisitos. Este será su diseño conceptual. Especifique claramente cualquier suposición que esté haciendo. Puede utilizar cualquier herramienta (software) para dibujar el EERD. Parte 3 Diseño Lógico 7- Se ha decidido utilizar un DBMS relacional para implementar la base de datos. Realice los pasos siguientes. a. Convierta su modelo conceptual (Parte 2) en un modelo lógico que se puede implementar en un DBMS relacional como Oracle. Durante este proceso se reemplazan las relaciones M-N y los atributos de valores múltiples con construcciones que se pueden implementar en el DBMS relacional. Dibuje EERD para el modelo lógico después de sus 2 modificaciones. Siéntase libre de cambiar su modelo conceptual si es necesario. segundo. Convierta el EERD (elemento a) en un diseño de base de datos. Documente su diseño en formato de esquema de base de datos. Parte 4 Normalización. Ahora, usted está listo para su implementación. Utilice convenciones de nomenclatura apropiadas para todas sus tablas y atributos. Normalize todas sus tablas a la tercera forma normal. Realice los cambios necesarios en el EERD de la Parte 2b. Explique por qué estos cambios deben hacerse. 8 - Dibuje un diagrama de dependencia para cada tabla de la Fase III a. 9 - Actualizar diccionario de datos de entrega anterior (parte 3 b.) Para agregar tipo de datos para cada atributo además de especificar si es clave primaria, clave extranjera, se permite NULL o su valor es ÚNICO. Parte 4 Implementación. 10 - Escribir DDL instrucciones SQL para crear bases de datos, tablas y todas las demás estructuras. Las claves primarias y claves foráneas deben estar definidas apropiadamente. No se requieren las limitaciones cuantitativas de la relación entre las entidades, que deben describirse en el diagrama EERD. 11- Utilice la sentencia Create View para crear las siguientes vistas: i. Símbolo de acciones: Esta vista devuelve el nombre de la empresa, la fecha de establecimiento de la compañía, el código de existencias, el número de acciones y los nombres de Exchange de todos los símbolos de acciones. 3 ii. Alta seguridad: Esta vista devuelve el código de acciones, el último precio de negociación y el volumen diario actual de cada símbolo y opción cuyo último precio de cotización es superior a 100. iii. Good-Trader: Esta vista devuelve todos los Oficios que tienen al menos 3 cuentas de al menos 2 corretajes. Iv. Stock-Traded: Esta vista devuelve el nombre de la empresa, el código de acciones y el número de acciones se ha negociado. V. Popular-Trader: Esta vista devuelve aquellos comerciantes que han negociado acciones más de 1 de todas las acciones negociadas. 12 - Proporcionar sentencias SQL para las siguientes consultas. Siéntase libre de usar cualquiera de las vistas que ha creado en la parte (e): vi. Vii. Viii. Ix. x. Xi. Xii. Xiii. Xiv. Xv. Para cada lista de empresas públicas el número de intercambios en los que cotiza sus acciones. Encuentre todos los Corretajes que no tienen ninguna cuenta. Lista de todos los intercambios que tienen acciones de la empresa pública establecida antes del 01 de enero de 1980. Encontrar cada comerciante que tiene exactamente una cuenta. Encuentre todas las Órdenes que hayan sido cumplidas por al menos 2 transacciones. Enumere todas las empresas en las que el número de acciones que cotiza exceda su número total de acciones. Enumere toda la cuenta de esos Popular-Traders. Enumere todas las existencias que han sido colocadas por Good-Traders. Enumere todas las transacciones que cumplieron plenamente sus dos órdenes. Enumere todas las cuentas que han sido puestas en orden de límite. 4 Student publicó una pregunta middot Jun 03, 2010 a las 12:40 pm