Databasisontwerp - Beurs Stelsel

Inleiding tot databasisontwerp Hierdie artikel / handleiding sal die basis van relasionele databasis ontwerp leer en verduidelik hoe om 'n goeie databasisontwerp te maak. Dit is 'n baie lang teks, maar ons raai om dit alles te lees. Die ontwerp van 'n databasis is in werklikheid redelik maklik, maar daar is 'n paar reëls om te hou by. Dit is belangrik om te weet wat hierdie reëls is nie, maar meer belangrik is om te weet waarom hierdie reëls bestaan, anders sal jy geneig om foute maak Standardization maak jou data model buigsaam en dit maak die werk met jou data baie makliker. Asseblief, neem die tyd om hierdie reëls te leer en toe te pas Die databasis wat gebruik word in hierdie artikel is ontwerp om met ons databasis ontwerp en modellering DeZign vir databasisse. 'N Goeie databasisontwerp begin met 'n lys van die data wat jy wil in jou databasis en wat jy wil in staat wees om te doen met die databasis later op te sluit. Dit kan almal in jou eie taal, sonder enige SQL. In hierdie stadium moet jy nie probeer om te dink in tabelle of kolomme, maar dink net: Wat het ek nodig om te weet Dont neem dit ook liggies, want as jy uitvind later dat jy iets vergeet het, gewoonlik moet jy al begin. dinge toe te voeg tot jou databasis is meestal 'n baie werk. Die identifisering van entiteite Die tipes inligting wat gestoor in die databasis is geroep entiteite. Hierdie entiteite bestaan ​​uit vier soorte: mense, dinge, gebeurtenisse, en plekke. Alles wat jy wil in 'n databasis te sit pas in een van hierdie kategorieë. Indien die inligting wat jy wil in te sluit nie die geval is pas in hierdie kategorieë, as wat dit is waarskynlik nie 'n entiteit, maar 'n eienskap van 'n entiteit, 'n kenmerk. Om die inligting in hierdie artikel en gebruik 'n voorbeeld te verduidelik. Verbeel jou dat jy is die skep van 'n webwerf vir 'n winkel, watter soort inligting het jy te doen het met in 'n winkel te verkoop jy jou produkte aan kliënte. Die winkel is 'n plek koop is 'n gebeurtenis Produkte is dinge en kliënte is mense. Dit is alle entiteite wat aangespreek moet word in jou databasis. Maar watter ander dinge gebeur wanneer die verkoop van 'n produk 'n kliënt kom in die winkel, benader die verkoper, vra 'n vraag en kry 'n antwoord. Verkopers ook deelneem, en omdat verkopers is mense, ons moet 'n verkopers entiteit. Die identifisering van verwantskappe Die volgende stap is om die verhouding tussen die entiteite te bepaal en om die aantal elemente van elke verhouding te bepaal. Die verhouding is die verband tussen die entiteite, net soos in die werklike wêreld: wat 'n mens entiteit doen met die ander, hoe dit verband hou met mekaar Byvoorbeeld, kliënte koop produkte, produkte verkoop aan kliënte, 'n verkoop bestaan ​​uit produkte, 'n verkoop gebeur in 'n winkel. Die kardinaliteit wys hoeveel van die een kant van die verhouding behoort aan hoeveel van die ander kant van die verhouding. Eerstens, moet jy om te sê vir elke verhouding, hoeveel van die een kant behoort aan presies 1 van die ander kant. Byvoorbeeld: Hoeveel kliënte behoort aan 1 koop Hoeveel verkope behoort aan 1 kliënt Hoeveel verkope plaasvind in 1 shop jy kry 'n lys soos volg: (let wel dat die produk verteenwoordig 'n tipe produk, nie 'n voorkoms van 'n produk) kliënte - verkope 1 kliënt kan koop iets 'n paar keer verkope - kliënte 1 verkoop word altyd deur 1 kliënt ten tyde kliënte - produkte 1 kliënt kan koop verskeie produkte produkte - kliënte 1 produk kan gekoop word deur verskeie kliënte kliënte - - winkels 1 kliënt kan koop in verskeie winkels winkels - kliënte, 1 winkel kan verskeie kliënte winkels ontvang - produkte in 1 winkel daar is verskeie produkte produkte - winkels 1 produk (tipe) verkoop kan word in verskeie winkels winkels - verkope in 1 winkel verskeie verkope kan my gemaak verkope - Winkels 1 koop kan net in 1 winkel gemaak word ten tyde Produkte - verkope 1 produk (tipe) kan gekoop word in verskeie verkope verkope - Produkte 1 verkoop kan uit verskeie bestaan produkte het ons noem alle verhoudings Daar is vier entiteite en elke entiteit het 'n verhouding met elke ander entiteit, sodat elke entiteit moet drie verhoudings te hê, en ook op die linkerkant van die verhouding drie keer. Bo, is 12 verhoudings genoem, wat is 43, so ons kan aflei dat alle verhoudings genoem. Nou goed sit die data saam met die kardinaliteit van die hele verhouding vind. Ten einde dit te doen, goed te stel die cardinalities per verhouding. Om dit te maklik om te doen, goed te pas die notasie 'n bietjie, maak deur te let op die agterste-verhouding andersom: Kliënte - Verkope 1 kliënt kan koop iets 'n paar keer Verkope - Kliënte 1 verkoop word altyd deur 1 kliënt aan die tyd die tweede verhouding sal ons omdraai sodat dit dieselfde entiteit orde as die eerste. Let op die pyltjie wat nou in die gesig gestaar na die ander kant Kliënte Verkope 1 kliënt kan iets 'n paar keer 1 koop: N. Kliënte Verkope - 1: N kliënte - Produkte - M: N kliënte - Winkels - M: N Verkope - Produkte - M: N Winkels - Verkope - 1: N Winkels - Produkte - M : n Dus, het ons twee 1-tot-baie verhoudings, en vier baie-tot-baie relationships. Between die entiteite is daar dalk 'n wedersydse afhanklikheid wees. Dit beteken dat die een item nie kan bestaan ​​as die ander item bestaan ​​nie. Byvoorbeeld, kan daar nie 'n verkoping wees as daar geen kliënte, en daar kan nie 'n verkoping wees as daar geen produkte. Die verhoudings Verkope - Kliënte en verkope - Produkte is verpligtend, maar die ander manier om dit nie die geval nie. 'N kliënt kan bestaan ​​sonder verkoop, en ook 'n produk kan bestaan ​​sonder koop. Dit is van belang vir die volgende stap. Rekursiewe Verhoudings Soms verwys 'n entiteit terug na homself. Byvoorbeeld, dink aan 'n werk hiërargie: 'n werknemer het 'n baas en die bosschef is 'n werknemer ook. Die kenmerk baas van die werknemers entiteit verwys terug na die werknemers entiteit. In 'n ERD (sien volgende hoofstuk) hierdie tipe verhouding is 'n lyn wat gaan uit van die entiteit en keer terug met 'n lekker lus om dieselfde entiteit. Oorbodig Verhoudings Soms in jou model wat jy sal 'n onnodige verhouding te kry. Dit is verhoudings wat reeds deur ander verhoudings aangedui, hoewel nie direk. In die geval van ons voorbeeld is daar 'n direkte verband tussen kliënte en produkte. Maar daar is ook verhoudings van kliënte te verkoop en uit verkope aan produkte, so indirek daar reeds 'n verband tussen kliënte en produkte deur middel van verkope. Die verhouding Kliënte Produkte is twee keer gedoen, en een van hulle is dus oorbodig. In hierdie geval, is die produkte net gekoop deur 'n verkoop, sodat die verhoudings Kliënte Produkte kan verwyder. Die model sal dan so lyk: Oplos Baie-tot-baie verhoudings Baie-tot-baie verhoudings (M: N) is nie direk moontlik in 'n databasis. Wat 'n M: N verhouding sê, is dat 'n aantal rekords van 'n tafel behoort aan 'n aantal rekords van 'n ander tafel. Iewers moet jy red wat rekords dit is en die oplossing is om die verhouding verdeel in twee een-tot-baie verhoudings. Dit kan gedoen word deur die skep van 'n nuwe entiteit wat tussen die verwante entiteite. In ons voorbeeld, daar is 'n baie-tot-baie-verhouding tussen verkope en produkte. Dit kan opgelos word deur die skep van 'n nuwe entiteit: verkope-produkte. Hierdie entiteit het 'n baie-tot-een verhouding met verkope, en 'n baie-tot-een verhouding met produkte. In logiese modelle is dit genoem 'n assosiatiewe entiteit en in fisiese databasis terme van hierdie staan ​​bekend as 'n skakel tafel of aansluiting tafel. In die voorbeeld is daar twee baie-tot-baie verhoudings wat opgelos moet word: Produkte Verkope en produkte winkels. Vir beide situasies moet daar word 'n nuwe entiteit, maar wat is daardie entiteit vir die produkte Sales verhouding, elke verkope sluit meer produkte. Die verhouding toon die inhoud van die verkoop. Met ander woorde, dit gee besonderhede oor die verkoop. So het die entiteit genoem Verkope besonderhede. Jy kan ook noem dit verkoop produkte. Die produkte winkels verhouding toon watter produkte is beskikbaar in die winkels, ook bekend as voorraad. Ons model sal nou soos volg lyk: Die identifisering skryf die data-elemente wat jy wil om te spaar vir elke entiteit is eienskappe genoem. Oor die produkte wat jy verkoop, wat jy wil weet, byvoorbeeld, wat die prys is, wat die naam van die vervaardiger is, en wat die tipe nommer is. Oor die kliënte wat jy ken hul kliënte nommer, hul naam, sowel as adres. Oor die winkels wat jy ken die plek-kode, die naam, die adres. Van die verkope wat jy weet wanneer dit gebeur het, waarin winkel, wat produkte verkoop, en die somtotaal van die verkoop. Van die verkoper weet jy sy personeel nommer, naam, sowel as adres. Wat sal presies ingesluit is nie van belang maar dit is nog steeds net oor wat jy wil red. Afgelei Data afkomstig data is data wat verkry word uit die ander data wat jy reeds gered. In hierdie geval is die somtotaal is 'n klassieke geval van afgeleide data. Jy weet presies wat verkoop is en wat elke produk koste, sodat jy kan altyd bereken hoeveel die somtotaal van die verkope is. So eintlik is dit nie nodig is om die somtotaal red. So hoekom is dit gered hier Wel, omdat dit 'n verkoop, en die prys van die produk kan wissel met verloop van tyd. 'N Produk kan geprys teen 10 € vandag en op 8 € volgende maand, en vir jou administrasie wat jy nodig het om te weet wat dit kos ten tyde van die koop, en die maklikste manier om dit te doen, is om dit hier te red. Daar is 'n baie meer elegante maniere, maar hulle is te groot vir hierdie artikel. Die aanbieding van entiteite en Verhoudings: Entiteit Verhoudings Diagram (ERD) Die Entiteit Verhoudings Diagram (ERD) gee 'n grafiese oorsig van die databasis. Daar is verskeie style en soorte DAAR diagramme. 'N Veel gebruikte notasie is die crowfeet notasie, waar entiteite verteenwoordig as reghoeke en die verhoudings tussen die entiteite verteenwoordig as lyne tussen die entiteite. Die tekens aan die einde van die lyne dui die tipe verhouding. Die kant van die verhouding wat is verpligtend vir die ander om te bestaan ​​sal deur 'n tikkie op die lyn aangedui word. Nie verpligtend entiteite word aangedui deur 'n sirkel. Baie aangedui deur 'n crowfeet de verhouding-lyn verdeel in drie lyne. In hierdie artikel maak ons ​​gebruik van DeZign vir databasisse te ontwerp en aan te bied ons databasis. A 1: A 1:: N verpligte verhouding: Toewys sleutels primêre sleutels 'n Primêre sleutel (PK) is een of meer data eienskappe wat 'n entiteit uniek identifiseer 1 verpligte verhouding word soos volg verteenwoordig. 'N sleutel wat bestaan ​​uit twee of meer spesifieke eienskappe word 'n saamgestelde sleutel. Alle eienskappe deel van 'n primêre sleutel moet 'n waarde in elke rekord (wat nie met leë hande gelaat kan word) en die kombinasie van die waardes binne hierdie eienskappe moet uniek in die tabel wees nie. In die voorbeeld is daar 'n paar voor die hand liggend kandidate vir die primêre sleutel. Kliënte het almal 'n kliënt nommer, produkte het almal 'n unieke produk nommer en die verkope het 'n verkope getal. Elkeen van hierdie data is uniek en elke rekord sal 'n waarde bevat, so hierdie eienskappe kan 'n primêre sleutel wees. Dikwels 'n heelgetal kolom word gebruik vir die primêre sleutel so 'n rekord kan maklik gevind word deur sy nommer. Link-entiteite gewoonlik verwys na die primêre sleutel eienskappe van die entiteite wat hulle skakel. Die primêre sleutel van 'n skakel-entiteit is gewoonlik 'n versameling van hierdie verwysing-eienskappe. Byvoorbeeld in die Salesdetails entiteit kon ons die kombinasie van die PKS van die verkope en produkte entiteite soos die PK van Salesdetails gebruik. Op hierdie wyse af te dwing ons dat dieselfde produk (tipe) kan slegs een keer in dieselfde veiling gebruik. Verskeie items van dieselfde soort produk in 'n verkoop moet aangedui word deur die hoeveelheid. In die ERD die primêre sleutel eienskappe word aangedui deur die teks PK agter die naam van die eienskap. In die voorbeeld het net die entiteit shop nie 'n voor die hand liggende kandidaat vir die PK, sodat ons sal 'n nuwe kenmerk vir daardie entiteit te stel: shopnr. Vreemde sleutels Die buitelandse Sleutel (SK) in 'n entiteit is die verwysing na die primêre sleutel van 'n ander entiteit. In die ERD sal dit kenmerk met SK aangedui agter sy naam. Die vreemde sleutel van 'n entiteit kan ook deel van die primêre sleutel, in so 'n geval die kenmerk met PF agter sy naam sal aangedui wees. Dit is gewoonlik die geval met die skakel-entiteite, omdat jy gewoonlik 'n skakel twee gevalle net een keer saam (met 1 koop net 1 produk tipe verkoop 1 keer). As ons almal skakel-entiteite, PKS en FKS in die ERD, kry ons die model soos hieronder getoon. Neem asseblief kennis dat die kenmerk produkte is nie meer nodig in verkope, want verkoop produkte is nou ingesluit in die skakel-tafel. In die verband-tafel 'n ander gebied is bygevoeg, hoeveelheid, wat aandui hoeveel produkte verkoop. Die veld hoeveelheid is ook bygevoeg in die voorraad-tafel, aan te dui hoeveel produkte is steeds in die winkel. Definiëring van die eienskappe Data Type Nou is dit tyd om uit te vind wat datatipes moet gebruik word vir die eienskappe. Daar is 'n baie verskillende tipes data. 'N Paar is gestandaardiseerde, maar baie databasisse het hul eie datatipes wat almal hul eie voordele. Sommige databasisse offerthe moontlikheid om jou eie datatipes te definieer, in die geval van die standaard tipes nie die dinge wat jy nodig het kan doen. Die standaard tipes data wat elke databasis weet, en is die meeste gebruik word, is: CHAR, Naam VARCHAR, teks, vlot, dubbel, en INT. Teks: CHAR (lengte) - sluit teks (karakters, getalle, leestekens.). CHAR het as kenmerk dat dit spaar altyd 'n vaste bedrag van posisies. As jy 'n CHAR (10) definieer jy kan bespaar tot maksimum tien posisies, maar as jy net twee posisies gebruik sal die databasis steeds red 10 posisies. Die oorblywende agt posisies sal gevul word deur spasies. Naam VARCHAR (lengte) - sluit teks (karakters, getalle, punktuasie.). Naam VARCHAR is dieselfde as CHAR, die verskil is dat Naam VARCHAR neem net soveel ruimte as wat nodig is. TEKS - kan groot hoeveelhede teks bevat. Afhangende van die tipe databasis kan hierdie voeg tot GB. Nommers: INT - bevat 'n positiewe of negatiewe heelgetal. Baie databasisse variasies van die INT, soos TINYINT, SMALLINT, MEDIUMINT, BIGINT, INT2, INT4, INT8. Hierdie variasies verskil van die INT net in die grootte van die figuur wat pas in dit. 'N Gereelde INT is 4 grepe (INT4) en pas syfers van -2147483647 om 2147483646, of as jy dit definieer as Ongetekende van 0 tot 4294967296. Die INT8, of BIGINT, kan selfs 'n groter in grootte te kry, 0-18446744073709551616, maar neem tot 8 grepe van disketspasie, selfs al is daar net 'n klein aantal in dit. Vlot, dubbel - Dieselfde idee as INT, maar kan ook Store drywende punt getalle. Moenie daarop dat dit nie altyd goed werk. Byvoorbeeld in MySQL berekening met hierdie drywende punt getalle is nie volmaak nie, (1/3) 3 tot gevolg sal hê met MySQLs dryf in 0,9999999, nie 1. Ander tipes: BLOB - vir binêre data soos files. INET - na IP-adresse. Ook bruikbare vir netmasks. Vir ons voorbeeld die datatipes is soos volg: Normalisering Normalisering maak jou data model buigsaam en betroubaar. Dit maak genereer sommige oorhoofse omdat jy gewoonlik meer tafels, maar dit stel jou in staat om baie dinge met jou datamodel te doen sonder om dit aan te pas. Normalisering, die eerste vorm Die eerste vorm van normalisering dat daar dalk geen herhalende groepe van kolomme in 'n entiteit. Ons kan 'n verkope entiteit met eienskappe vir elk van die produkte wat gekoop is geskep. Dit sal lyk soos volg: Wat is verkeerd oor dit wat nou net 3 produkte verkoop kan word. As jy wil hê om te verkoop 4 produkte, as jy wil hê om 'n tweede veiling begin of jou data model aan te pas deur die byvoeging van product4 eienskappe. Beide oplossings is ongewenste. In sulke gevalle moet jy altyd 'n nuwe entiteit wat jou verwys na die ou een deur 'n een-tot-baie-verhouding. Normalisering, die tweede vorm Die tweede vorm van normalisering bepaal dat al die eienskappe van 'n entiteit ten volle afhanklik is van die hele primêre sleutel moet wees. Dit beteken dat elke kenmerk van 'n entiteit kan slegs geïdentifiseer deur die hele primêre sleutel. Veronderstel ons het die datum in die Salesdetails entiteit: Hierdie entiteit is nie volgens die tweede normalisering vorm, want in staat te wees om op te kyk die datum van 'n verkoop, kan ek nie hoef te weet wat verkoop word (Productnr), die enigste ding wat ek nodig het om te weet, is die verkope getal. Dit is opgelos deur die splitsing van die tafels in die verkope en die Salesdetails tabel: Nou elke kenmerk van die entiteite is afhanklik van die hele PK van die entiteit. Die datum is afhanklik van die verkope nommer, en die hoeveelheid hang af van die verkope nommer en die verkoop van die produk. Normalisering, die derde vorm Die derde vorm van normalisering bepaal dat al die eienskappe hoef direk afhanklik van die primêre sleutel, en nie op ander eienskappe te wees. Dit lyk of wat die tweede vorm van normalisering state wees, maar in die tweede vorm is eintlik gesê die teenoorgestelde. In die tweede vorm van normalisering wys jy uit eienskappe deur die PK, in die derde vorm van normalisering elke kenmerk moet afhanklik van die PK te wees, en niks anders nie. In hierdie geval is die prys van 'n los produk is afhanklik van die bestelling nommer, en die bestel nommer is afhanklik van die model nommer en die verkope getal. Dit is nie volgens die derde vorm van normalisering. Weereens, verdeel die tafels lost hierdie. Normalisering, Meer Vorms Daar is meer normalisering vorms as die drie bogenoemde vorms, maar dit is nie van groot belang vir die gemiddelde gebruiker. Hierdie ander vorme is hoogs gespesialiseerde vir sekere aansoeke. As jy vashou aan die ontwerp reëls en die in hierdie artikel genoem normalisering, sal jy 'n ontwerp wat 'n groot vir die meeste aansoeke werk te skep. Genormaliseer Data Model As jy die normalisering reëls toe te pas, sal jy vind dat die vervaardiger in die produk tabel ook 'n aparte tafel moet wees: Woordelys eienskappe - gedetailleerde data oor 'n entiteit, soos prys, lengte, naam Cardinaliteit - die verhouding tussen twee entiteite , in syfers. Byvoorbeeld, kan 'n persoon verskeie bestellings te plaas. Entiteite - abstrakte data wat jy red in 'n databasis. Byvoorbeeld: kliënte, produkte. Vreemde sleutel (SK) - 'n verwysing na die Primêre Sleutel van 'n ander tafel. Vreemde sleutel-kolomme kan slegs waardes wat bestaan ​​in die Primêre Sleutel kolom dat hulle verwys na bevat. Sleutel - 'n sleutel gebruik om te wys rekords. Die mees bekende sleutel is die primêre sleutel (sien Primêre Sleutel). Normalisering - 'N buigsame data model moet sekere reëls te volg. Toepassing van hierdie reëls is normaliseer genoem. Primêre sleutel - een of meer kolomme binne 'n tafel wat saam 'n unieke kombinasie van waardes waarvolgens elke rekord afsonderlik kan daarop gewys vorm. Byvoorbeeld: die kliënt getalle, of die reeksnommer van 'n produk. Hulpbronne Leer DeZign vir databasisse. Hier is meer oor DeZign vir databasisse. Aan die begin met DeZign vir databasisse. Begin 'n datamodel direk. tipes vertoon data in 'n diagram. Leer hoe om die tipe data en / of domein inligting te vertoon in die entiteit bokse op jou diagram. Kry produkte en tegnologie Bou jou volgende datamodel met DeZign vir databasisse verhoor sagteware, beskikbaar vir aflaai direk vanaf Datanamics aflaai section. U.S. Voorrade databasis Die Amerikaanse aandele databasis is die nuutste toevoeging tot suite van GFD produkte. Die USDatabase komplimenteer die GFDatabase deur sodat jy die finansiële aanwysers kombineer van die Verenigde State en 200 ander lande met die historiese prys data op meer as 40,000 individuele huidige en gedenoteer aandele van elke Amerikaanse ruil. Die USDatabase is die mees omvattende versameling van individuele sekuriteite ooit saamgestel insluitend gedenoteer aandele van nasionale en plaaslike Aandelebeurse soos NASDAQ, die New York, Chicago, Philadelphia of Boston Stock Market Exchange. Die USDatabase sluit in: die VSA Stock databasis bied die mees omvattende historiese dekking en 'n indrukwekkende versameling van die huidige dekking mark, insluitend grondbeginsels. Ons daaglikse aandelemark geskiedenis begin so vroeg as 1962 vir groot Amerikaanse sekuriteite. Ons bied die oorspronklike handel waardes vir elke dag, en jou in staat stel om aan te pas vir split en verdelings. Benewens die aandelemark prys en volume vir elke dag, maar ons verskaf ook inligting oor die datum en bedrag van dividendbetalings, split en uitkerings deur elke maatskappy. GFD kombineer historiese inligting nie net op die komponente van die groot indekse soos die Dow Jones Industrial Average en SampP 500, maar ook historiese inligting oor sektor indekse. Hierdie inligting skakel direk na die data op individuele aandele. Byvoorbeeld, kan jy ontleed hoe olievoorrade uitgevoer in die 1970's of bestudeer die gedrag van die sagteware aandele gedurende die 1990's. Geen ander data verkoper toelaat vir hierdie deursnit van analise in een bron. Oorspronklike leier die verskaffing van volledige data Globale finansiële inligting is die oorspronklike leier in finansiële data navorsing, die uitbreiding van bestaande mark data indeks reeks reeds in die algemene praktyk in die mark aktiwiteite, en die skepper van die algemeen gebruik, privaat-indeks soos die Wêreldbank Ex VSA voorraad indeks. GFD het onlangs vrygestel itsUS Aandeel databasis en sy Britse Aandeel databasis bevat inhoud keer gebruik net intern te GFDs produk lyn in stand te hou en te verwys GFDs Wêreld Core Data en die GFDatabase steek. Vandag is hierdie inhoud is toeganklik vir die finansiële gemeenskap deur middel van verskeie aanpas produkte en dienste. In byvoeging tot die korporatiewe aksie dienste EVENTSintimeDATA verskaf die finansiële gemeenskap met 'n volledige dekking van die aandelemarkte daardie wêreld van finansies sedert 1691. Ons dekking rondom oop en geslote-einde fondse Mutual fondse, aandele, Amerikaanse Depositobewyse, Eenheid Investment Trust en veel oorheers meer. Ons korporatiewe aksie en dividend data word intern ingesamel op 'n daaglikse basis deur 'n ervare span navorsers met 'n noukeurige bestuurspan. Tydens die versameling van die historiese inhoud, GFD benut sy proses te verifieer en kruisverwysing die inligting voor die insluiting daarvan in ons databasis produkte. Dit word dan ontleed en geredigeer vir akkuraatheid. Ons EVENTSintimeDATA versamel, direk vanaf aandelebeurse, maatskappy vylsels, persverklarings, deposito, oordrag agente, tydskrifte, en van die maatskappy. Ons bied die nuutste inligting beskikbaar op die Verenigde State van Amerika Stock Market en die maatskappye London Stock Market insluitend: naamsveranderinge, samesmeltings, verkrygings, aflossings, Stock Splits, volwassenheid Tender aanbiedings, reorganisasie, Stock Splits, byvoordele Aandele uitstaande inligting. GFD openbaar ook ander interessante inligting nie algemeen bekend is oor die data-reeks. Ons direkte kliënt reaksie op versoeke om inligting is vir niemand, as ons reaksie op die aanspreek van kommer oor die akkuraatheid van data of berekeningsmetodes. Oor ons markdata Pryse erken as die industrie standaard van uitnemendheid in navorsing gehalte tegniese data sekuriteite, Die GFDATABASES bied professionele persone met data wat nodig is om ingeligte beleggingsbesluite en handel besluite te neem. Ons aktief te bestuur van 'n eie sekuriteite databasis betroubare, betroubare, bruikbare mark data verskaf. Ons versigtig en gedetailleerde proses van insameling, reiniging en verifiëring data is omvattende op elke vlak. Ons doen dit alles teen 'n baie mededingende pryse. Ons bied verskeie vlakke van databasis pakkette vir individuele adviseurs om groot kommersiële maatskappye of akademiese navorsers, professore en studente. Elke markdag ons data navorsingspanne die data bestudeer van verskeie verskaffers met behulp van gespesialiseerde rekenaarprogramme en gebruik die ou mode manier direk lees van die data in die stelsel. GFD is deeglike, ongerymdhede is gemerk, met die hand nagevors en die jongste markgebeure opgeneem om te verseker akkurate inligting is gelewer. Ons lewer akkuraatheid en reageer onmiddellik om data uitdagings. Ons historiese sekuriteite databasis dek alle genoteerde Noord-Amerikaanse aandele, aandele London Stock Market. Ons lewer beide historiese en daaglikse update data in volle gedokumenteer, ASCII lêer formate gelewer via veilige FTP. Ons bied hierdie inligting aan kliënte in een van twee beskikbare voere. Ons ten volle Aangepas / in mekaar data voed bied 'n sleutel oplossing vir kaarte en grafieke om jou plaaslike databasis. Alternatiewelik, is ons Onaangepaste / Onsamehangende data voer wat gerig is op alle instellings wat 'n historiese perspektief met geen oorlewing vooroordeel. Dit voer lewer markdata die manier waarop dit was oorspronklik gerapporteer deur die uitruil. Kwaliteit, akkuraatheid en reageer kliëntediens is die rede waarom baie prominente sekuriteite maatskappye, finansiële uitgewers en belegging instellings kies HSD as hul data bron. GFD-Finaeon bied ook die eksklusiewe AeonXL invoegsel wat data in Excel formaat vinnig en maklik sal aflaai. Hierdie metode is ideaal vir maatskappye wat 'n begeerte om verskillende tipes data te trek van maand tot maand. Ons streef voortdurend daarna om ons produkte en dienste ten einde die beste toegang tot die jongste finansiële veranderinge moontlik deur ons use stelsels te verbeter. Bel nou om te sien hoe ons die integrasie van die EVENTSintimeDATA, Die wêreld Core Data, Die Amerikaanse aandele en die Verenigde Koninkryk Aandeel Databasisse jou belegging praktyke en handel besluite kan vervolmaak. GFDs omvattende navorsing het dit toegelaat om beter dekking van huidige en historiese Amerikaanse aandelemarkte bied. Deur die kombinasie van die Cowles indekse en SampP GICS data, het GFD geskep deurlopende,-ketting gekoppel datareeks terug strek tot 1871. Soortgelyke navorsingsmetodologieë het onthul 'n intraday data indeks vir die Dow Jones Industrial Average terug te gaan na 1933. Hierdie onverbiddelik navorsingsmetodes is wat GFD het sy reputasie gebou op en wat ons kliënte het gekom om te verwag. SURVIVOR BIAS GRATIS Globale finansiële inligting verskaf die einde van die dag sluitingstyd pryse vir individuele Verenigde State Aandele asook historiese data op meer as 11.000 Amerikaanse aandele en dek 30000 gestaak aandele UNIEKE sagteware funksies Skakel vandag vir 'n aanlyn aanbieding van die unieke kenmerk van soek samestellende lede van die SampP 500 en die Dow Jones 30. 1-877-328-2999 kan dit dekade die Volgende 1930 - a Review van die Eerste Wêreldoorlog Stock markte in die 1920's kyk na of die huidige beermark kan lei tot 'n globale ineenstorting aandelemark soortgelyk aan die 1930's. MEBANE T. Faber en Eric W. Richardson, Die Ivy Portefeulje, John Wiley amp Sons, 2009View die stap-vir-stap oplossing vir: Databasisontwerp vir 'n Stock Trading System Die Hierdie vraag is op 4 Desember 2010. Kyk die antwoord databasisontwerp vir 'n Stock Trading System The Stock Trading System is 'n outomatiese stelsel vir die handel aandele en opsies van die openbaar verhandelde maatskappye en dit het die volgende data vereistes: 'n maatskappy is uniek bepaal deur sy naam, terwyl dit ook 'n hoofkwartier adres en 'n gevestigde datum. Adres is 'n saamgestelde eienskap, wat komponente straatnommer, 'n woonstel nommer, stad, straat en poskode. Sommige maatskappye het in die openbaar verhandel algemene aandele, en is vernoem openbare maatskappye. Elke publieke maatskappy het slegs een so 'n voorraad, elk voorraad het 'n unieke voorraad kode en gespesifiseerde aantal aandele. Elke voorraad ambagte op een of meer ruil, maar die getal van handel ruil kan nie meer as 9. 'n ruil is uniek bepaal deur sy naam. Daar is 'n beurs simbool assosieer met 'n voorraad, wat gebruik word om ambagte op 'n beurs. Dieselfde voorraad kan verskillende simbole op verskillende ruil het. 'N opsie op 'n beurs simbool is 'n sekuriteit wat uniek is bepaal deur die tipe, beurs simbool, trefprys, en vervaldatum. 'N opsie handel oor dieselfde ruil as sy beurs simbool. Die tipe van 'n opsie is nie 'n put of 'n oproep. Dit kan nie wees beide, en dit kan nie iets anders wees. Die laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie moet aangeteken word. Voorrade en opsies word besit en verhandel deur handelaars. 'N handelaar het 'n naam en 'n belasting ID. Die belasting ID bepaal uniek die handelaar. Die waarde van belasting ID is tussen 000001 en 900000. Handelaars nie direk handel, maar via makelaars. 'N makelaar is uniek bepaal deur sy naam en die staat. Elke makelaar handel oor een of meer ruil en betaal 'n vaste jaarlikse fooi vir elke ruil dit handel. Die fooi kan verskillend vir elke makelaar / ruil paar wees. 'N handelaar besit ten minste een rekening met ten minste een stel. Sy / hy kan meer as een rekening te hou met dieselfde stel en te hanteer meer as een stel. 'N rekening uniek bepaal deur makelaars en rekeningnommer. 'N makelaar kan geen rekeninge het. Elke rekening het presies een eienaar. Rekeninge hou sekuriteite en kontant. Let daarop dat 'n voorraad gekoop op een ruil op 'n ander verkoop kan word, so dit is aandele, nie simbole, wat gehou word. Moenie vergeet om opsies in rekeninge insluit. Handelaars plaas handel bestellings via hul makelaars. 'N bevel spesifiseer die rekening, presies een simbool of opsie om handel te dryf, bod (koop) of vra (verkoop), aantal aandele handel te dryf, en die einde verstryking. Daar is twee tipes van bestellings: mark en beperk. 'N beperking orde het die prys limiet bykomend tot die genoemde eiendomme. Die makelaars en orde ID uniek aan die orde te bepaal. 'N uitgevoer word in (moontlik gedeeltelike) vervulling van twee bestellings. Elke transaksie bevat die volgende inligting: presies een bod orde, presies een vra orde, aantal aandele, transaksie prys, kommissies deur die koper en die verkoper om hul makelaars, en die datum en tyd betaal. Ruil en transaksie nommer dien as unieke die transaksie te bepaal. Let daarop dat 'n bevel kan gevul word deur 'n paar transaksies. Die aandele en opsies verhandel as hul bestellings vervul deur 'n paar transaksies. Termyn papier Vrae Deel-1 Vereiste Analise 1. Identifiseer die belangrikste entiteite van hierdie voorraad handel stelsel. 2. Kan jy aan nog ander as die een in die data vereistes toe te voeg aan die voorraad handel stelsel 3. beskryf entiteite is die vermoë om 'n model super-tipe / subtipe verhoudings waarskynlik belangrik in sulke omgewing te wees Hoekom of hoekom nie 4 . Kan jy dink aan nog 4 reëls (behalwe die een uitdruklik hierbo beskryf) wat waarskynlik gebruik word in 'n voorraad handel stelsel Voeg jou reëls om die data vereistes te implementeer, is. 5. Motiveer die gebruik van 'n relasionele DBBS soos Oracle of SQL server vir hierdie stelsel. Deel 2- Konseptuele Ontwerp 6- Teken 'n Eerd om hierdie stel vereistes akkuraat verteenwoordig. Dit sal jou Konseptuele Ontwerp wees. Dit is duidelik dat enige aannames wat jy maak spesifiseer. Jy kan enige gereedskap (sagteware) gebruik om die Eerd trek. Deel 3 Logiese Design 7- Daar is besluit om 'n relasionele DBBS gebruik om die databasis te implementeer. Voer die volgende stappe. a. Skakel jou Konseptuele model (Deel 2) om 'n logiese model wat in 'n relasionele DBBS soos Oracle geïmplementeer kan word. Tydens hierdie proses te vervang jy M-N verhoudings en multi-gewaardeer eienskappe met konstrukte wat in die relasionele DBBS geïmplementeer kan word. Teken Eerd vir die logiese model na jou veranderinge. Voel vry om jou konseptuele model verander as dit nodig is. b. Skakel die Eerd (item a) om 'n databasis ontwerp. Dokumenteer jou ontwerp in databasis skedule formaat. Deel 4 Normalisering. Nou, is jy gereed vir implementering. Gebruik gepaste benaming konvensies vir al jou tafels en eienskappe. Normaliseer al jou tafels aan derde normaalvorm. Maak die nodige veranderinge aan die Eerd van Deel 2b. Verduidelik waarom hierdie veranderinge wat nodig is om gedoen word. 8 - Teken 'n afhanklikheid diagram vir elke tafel van Fase III a. 9 - (. Deel 3 b) Werk datawoordeboek from previous lewering aan datatipe voeg vir elke kenmerk bykomend tot spesifiseer as dit primêre sleutel, vreemde sleutel, NULL toegelaat word, of die waarde daarvan is uniek. Deel 4 Implementering. 10 - Skryf DDL SQL-stellings om databasis, tafels en alle ander strukture te skep. Primêre sleutels en vreemde sleutels moet toepaslik gedefinieer. Die hoeveelheid beperkinge van die verhouding tussen die entiteite wat in Eerd diagram moet beskryf word, is nie nodig nie. 11- Gebruik die skep View verklaring aan die volgende aansigte te skep: Ek. Stock-simbool: Hierdie siening gee die Maatskappy Naam, maatskappy gestig Datum, Stock Kode, aantal aandele en Exchange name van alle voorraad simbole. II. Hoë-sekuriteit: Hierdie siening terugkeer voorraad kode, laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie wat verlede verhandelingsprys is hoër as 100. iii. Goeie-Trader: Hierdie siening terug al die Trades wat ten minste 3 rekenings van ten minste 2 makelaars. iv. Stock-Verhandelde: Hierdie siening gee die naam vir maatskappy, voorraad en nommer van aandele is verhandel. v Popular-Trader:. Hierdie siening terugkeer diegene handelaars wat aandele verhandel meer as 1 van alle aandele verhandel. 12 - Verskaf SQL-stellings vir die volgende navrae. Voel vry om enige van die standpunte wat jy in deel (e) gebruik: vi. Vir elke openbare maatskappy lys van die aantal beurse wat sy voorraad ambagte op. vii. Vind al Makelarye wat nie enige rekeninge het nie. viii. Wys alle Effektebeurse wat voorraad het van die gevestigde voor 1 Januarie, 1980. ix publieke maatskappy. Vind elke handelaar wat presies 'n rekening het. x. Vind alle bestellings wat reeds vervul deur ten minste 2 transaksies. XI. Wys alle maatskappye waar die getal van sy verhandel aandele sy totale aantal aandele oorskry. xii. Lys al die rekening van dié gewilde-Handelaars. xiii. Lys al die aandele wat deur Good-Handelaars geplaas bestellings. xiv. Wys alle transaksies ten volle sy twee bestellings vervul. XV. Lys al die rekeninge wat limiet bestelling geplaas. Student gepos word 'n vraag middot 30 November 2010 by 10:23 amView die stap-vir-stap oplossing vir: Databasisontwerp vir 'n Stock Trading System Data Hierdie vraag is op 3 Junie 2010. Kyk die antwoord databasis Ontwerp vir 'n Stock Trading System vereistes data: The Stock Trading System is 'n outomatiese stelsel vir die handel aandele en opsies van die openbaar verhandelde maatskappye en dit het die volgende data vereistes: 'n maatskappy is uniek bepaal deur sy naam, terwyl dit ook 'n hoofkwartier adres en 'n gevestigde datum. Adres is 'n saamgestelde eienskap, wat komponente straatnommer, 'n woonstel nommer, stad, straat en poskode. Sommige maatskappye het in die openbaar verhandel algemene aandele, en is vernoem openbare maatskappye. Elke publieke maatskappy het slegs een so 'n voorraad, elk voorraad het 'n unieke voorraad kode en gespesifiseerde aantal aandele. Elke voorraad ambagte op een of meer ruil, maar die getal van handel ruil kan nie meer as 9. 'n ruil is uniek bepaal deur sy naam. Daar is 'n beurs simbool assosieer met 'n voorraad, wat gebruik word om ambagte op 'n beurs. Dieselfde voorraad kan verskillende simbole op verskillende ruil het. 'N opsie op 'n beurs simbool is 'n sekuriteit wat uniek is bepaal deur die tipe, beurs simbool, trefprys, en vervaldatum. 'N opsie handel oor dieselfde ruil as sy beurs simbool. Die tipe van 'n opsie is nie 'n put of 'n oproep. Dit kan nie wees beide, en dit kan nie iets anders wees. Die laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie moet aangeteken word. Voorrade en opsies word besit en verhandel deur handelaars. 'N handelaar het 'n naam en 'n belasting ID. Die belasting ID bepaal uniek die handelaar. Die waarde van belasting ID is tussen 000001 en 900000. Handelaars nie direk handel, maar via makelaars. 'N makelaar is uniek bepaal deur sy naam en die staat. Elke makelaar handel oor een of meer ruil en betaal 'n vaste jaarlikse fooi vir elke ruil dit handel. Die fooi kan verskillend vir elke makelaar / ruil paar wees. 'N handelaar besit ten minste een rekening met ten minste een stel. Sy / hy kan meer as een rekening te hou met dieselfde stel en te hanteer meer as een stel. 'N rekening uniek bepaal deur makelaars en rekeningnommer. 'N makelaar kan geen rekeninge het. Elke rekening het presies een eienaar. Rekeninge hou sekuriteite en kontant. Let daarop dat 'n voorraad gekoop op een ruil op 'n ander verkoop kan word, so dit is aandele, nie simbole, wat gehou word. Moenie vergeet om opsies in rekeninge insluit. Handelaars plaas handel bestellings via hul makelaars. 'N bevel spesifiseer die rekening, presies een simbool of opsie om handel te dryf, bod (koop) of vra (verkoop), aantal aandele handel te dryf, en die einde verstryking. Daar is twee tipes van bestellings: mark en beperk. 'N beperking orde het die prys limiet bykomend tot die genoemde eiendomme. Die makelaars en orde ID uniek aan die orde te bepaal. 'N uitgevoer word in (moontlik gedeeltelike) vervulling van twee bestellings. Elke transaksie bevat die volgende inligting: presies een bod orde, presies een vra orde, aantal aandele, transaksie prys, kommissies deur die koper en die verkoper om hul makelaars, en die datum en tyd betaal. Ruil en transaksie nommer dien as unieke die transaksie te bepaal. Let daarop dat 'n bevel kan gevul word deur 'n paar transaksies. Die aandele en opsies verhandel as hul bestellings vervul deur 'n paar transaksies. Termyn papier Vrae Deel-1 Vereiste Analise 1. Identifiseer die belangrikste entiteite van hierdie voorraad handel stelsel. 2. Kan jy aan nog ander as die een in die data vereistes toe te voeg aan die voorraad handel stelsel 3. beskryf entiteite is die vermoë om 'n model super-tipe / subtipe verhoudings waarskynlik belangrik in sulke omgewing te wees Hoekom of hoekom nie 4 . Kan jy dink aan nog 4 reëls (behalwe die een uitdruklik hierbo beskryf) wat waarskynlik gebruik word in 'n voorraad handel stelsel Voeg jou reëls om die data vereistes te implementeer, is. 5. Motiveer die gebruik van 'n relasionele DBBS soos Oracle of SQL server vir hierdie stelsel. Deel 2- Konseptuele Ontwerp 6- Teken 'n Eerd om hierdie stel vereistes akkuraat verteenwoordig. Dit sal jou Konseptuele Ontwerp wees. Dit is duidelik dat enige aannames wat jy maak spesifiseer. Jy kan enige gereedskap (sagteware) gebruik om die Eerd trek. Deel 3 Logiese Design 7- Daar is besluit om 'n relasionele DBBS gebruik om die databasis te implementeer. Voer die volgende stappe. a. Skakel jou Konseptuele model (Deel 2) om 'n logiese model wat in 'n relasionele DBBS soos Oracle geïmplementeer kan word. Tydens hierdie proses te vervang jy M-N verhoudings en multi-gewaardeer eienskappe met konstrukte wat in die relasionele DBBS geïmplementeer kan word. Teken Eerd vir die logiese model na jou veranderinge. Voel vry om jou konseptuele model verander as dit nodig is. b. Skakel die Eerd (item a) om 'n databasis ontwerp. Dokumenteer jou ontwerp in databasis skedule formaat. Deel 4 Normalisering. Nou, is jy gereed vir implementering. Gebruik gepaste benaming konvensies vir al jou tafels en eienskappe. Normaliseer al jou tafels aan derde normaalvorm. Maak die nodige veranderinge aan die Eerd van Deel 2b. Verduidelik waarom hierdie veranderinge wat nodig is om gedoen word. 8 - Teken 'n afhanklikheid diagram vir elke tafel van Fase III a. 9 - (. Deel 3 b) Werk datawoordeboek from previous lewering aan datatipe voeg vir elke kenmerk bykomend tot spesifiseer as dit primêre sleutel, vreemde sleutel, NULL toegelaat word, of die waarde daarvan is uniek. Deel 4 Implementering. 10 - Skryf DDL SQL-stellings om databasis, tafels en alle ander strukture te skep. Primêre sleutels en vreemde sleutels moet toepaslik gedefinieer. Die hoeveelheid beperkinge van die verhouding tussen die entiteite wat in Eerd diagram moet beskryf word, is nie nodig nie. 11- Gebruik die skep View verklaring aan die volgende aansigte te skep: Ek. Stock-simbool: Hierdie siening gee die Maatskappy Naam, maatskappy gestig Datum, Stock Kode, aantal aandele en Exchange name van alle voorraad simbole. II. Hoë-sekuriteit: Hierdie siening terugkeer voorraad kode, laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie wat verlede verhandelingsprys is hoër as 100. iii. Goeie-Trader: Hierdie siening terug al die Trades wat ten minste 3 rekenings van ten minste 2 makelaars. iv. Stock-Verhandelde: Hierdie siening gee die naam vir maatskappy, voorraad en nommer van aandele is verhandel. v Popular-Trader:. Hierdie siening terugkeer diegene handelaars wat aandele verhandel meer as 1 van alle aandele verhandel. 12 - Verskaf SQL-stellings vir die volgende navrae. Voel vry om enige van die standpunte wat jy in deel (e) gebruik: vi. Vir elke openbare maatskappy lys van die aantal beurse wat sy voorraad ambagte op. vii. Vind al Makelarye wat nie enige rekeninge het nie. viii. Wys alle Effektebeurse wat voorraad het van die gevestigde voor 1 Januarie, 1980. ix publieke maatskappy. Vind elke handelaar wat presies 'n rekening het. x. Vind alle bestellings wat reeds vervul deur ten minste 2 transaksies. XI. Wys alle maatskappye waar die getal van sy verhandel aandele sy totale aantal aandele oorskry. xii. Lys al die rekening van dié gewilde-Handelaars. xiii. Lys al die aandele wat deur Good-Handelaars geplaas bestellings. xiv. Wys alle transaksies ten volle sy twee bestellings vervul. XV. Lys al die rekeninge wat limiet bestelling geplaas. Aangeheg is 'n makliker weergawe van die dokument te sien. Ek het regtig waardeer die hulp met hierdie monster van 'n opdrag. Dankie Aanhegselvoorskou Aflaai beslaglegging databasis Ontwerp vir 'n Stock Trading System Data vereistes: The Stock Trading System is 'n outomatiese stelsel vir die handel aandele en opsies van die openbaar verhandelde maatskappye en dit het die volgende data vereistes: 'n maatskappy is uniek bepaal deur sy naam, terwyl het ook 'n hoofkwartier adres en 'n gevestigde datum. Adres is 'n saamgestelde eienskap, wat komponente straatnommer, 'n woonstel nommer, stad, straat en poskode. Sommige maatskappye het in die openbaar verhandel algemene aandele, en is vernoem openbare maatskappye. Elke publieke maatskappy het slegs een so 'n voorraad, elk voorraad het 'n unieke voorraad kode en gespesifiseerde aantal aandele. Elke voorraad ambagte op een of meer ruil, maar die getal van handel ruil kan nie meer as 9. 'n ruil is uniek bepaal deur sy naam. Daar is 'n beurs simbool assosieer met 'n voorraad, wat gebruik word om ambagte op 'n beurs. Dieselfde voorraad kan verskillende simbole op verskillende ruil het. 'N opsie op 'n beurs simbool is 'n sekuriteit wat uniek is bepaal deur die tipe, beurs simbool, trefprys, en vervaldatum. 'N opsie handel oor dieselfde ruil as sy beurs simbool. Die tipe van 'n opsie is nie 'n put of 'n oproep. Dit kan nie wees beide, en dit kan nie iets anders wees. Die laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie moet aangeteken word. Voorrade en opsies word besit en verhandel deur handelaars. 'N handelaar het 'n naam en 'n belasting ID. Die belasting ID bepaal uniek die handelaar. Die waarde van belasting ID is tussen 000001 en 900000. Handelaars nie direk handel, maar via makelaars. 'N makelaar is uniek bepaal deur sy naam en die staat. Elke makelaar handel oor een of meer ruil en betaal 'n vaste jaarlikse fooi vir elke ruil dit handel. Die fooi kan verskillend vir elke makelaar / ruil paar wees. 'N handelaar besit ten minste een rekening met ten minste een stel. Sy / hy kan meer as een rekening te hou met dieselfde stel en te hanteer meer as een stel. 'N rekening uniek bepaal deur makelaars en rekeningnommer. 'N makelaar kan geen rekeninge het. Elke rekening het presies een eienaar. Rekeninge hou sekuriteite en kontant. Let daarop dat 'n voorraad gekoop op een ruil op 'n ander verkoop kan word, so dit is aandele, nie simbole, wat gehou word. Moenie vergeet om opsies in rekeninge insluit. Handelaars plaas handel bestellings via hul makelaars. 'N bevel spesifiseer die rekening, presies een simbool of opsie om handel te dryf, bod (koop) of vra (verkoop), aantal aandele handel te dryf, en die einde verstryking. Daar is twee tipes van bestellings: mark en beperk. 'N beperking orde het die prys limiet bykomend tot die 1 genoemde eiendomme. Die makelaars en orde ID uniek aan die orde te bepaal. 'N uitgevoer word in (moontlik gedeeltelike) vervulling van twee bestellings. Elke transaksie bevat die volgende inligting: presies een bod orde, presies een vra orde, aantal aandele, transaksie prys, kommissies deur die koper en die verkoper om hul makelaars, en die datum en tyd betaal. Ruil en transaksie nommer dien as unieke die transaksie te bepaal. Let daarop dat 'n bevel kan gevul word deur 'n paar transaksies. Die aandele en opsies verhandel as hul bestellings vervul deur 'n paar transaksies. Termyn papier Vrae Deel-1 Vereiste Analise 1. Identifiseer die belangrikste entiteite van hierdie voorraad handel stelsel. 2. Kan jy aan nog ander as die een in die data vereistes toe te voeg aan die voorraad handel stelsel 3. beskryf entiteite is die vermoë om 'n model super-tipe / subtipe verhoudings waarskynlik belangrik in sulke omgewing te wees Hoekom of hoekom nie 4 . Kan jy dink aan nog 4 reëls (behalwe die een uitdruklik hierbo beskryf) wat waarskynlik gebruik word in 'n voorraad handel stelsel Voeg jou reëls om die data vereistes te implementeer, is. 5. Motiveer die gebruik van 'n relasionele DBBS soos Oracle of SQL server vir hierdie stelsel. Deel 2- Konseptuele Ontwerp 6- Teken 'n Eerd om hierdie stel vereistes akkuraat verteenwoordig. Dit sal jou Konseptuele Ontwerp wees. Dit is duidelik dat enige aannames wat jy maak spesifiseer. Jy kan enige gereedskap (sagteware) gebruik om die Eerd trek. Deel 3 Logiese Design 7- Daar is besluit om 'n relasionele DBBS gebruik om die databasis te implementeer. Voer die volgende stappe. a. Skakel jou Konseptuele model (Deel 2) om 'n logiese model wat in 'n relasionele DBBS soos Oracle geïmplementeer kan word. Tydens hierdie proses te vervang jy M-N verhoudings en multi-gewaardeer eienskappe met konstrukte wat in die relasionele DBBS geïmplementeer kan word. Teken Eerd vir die logiese model na jou 2 wysigings. Voel vry om jou konseptuele model verander as dit nodig is. b. Skakel die Eerd (item a) om 'n databasis ontwerp. Dokumenteer jou ontwerp in databasis skedule formaat. Deel 4 Normalisering. Nou, is jy gereed vir implementering. Gebruik gepaste benaming konvensies vir al jou tafels en eienskappe. Normaliseer al jou tafels aan derde normaalvorm. Maak die nodige veranderinge aan die Eerd van Deel 2b. Verduidelik waarom hierdie veranderinge wat nodig is om gedoen word. 8 - Teken 'n afhanklikheid diagram vir elke tafel van Fase III a. 9 - (. Deel 3 b) Werk datawoordeboek from previous lewering aan datatipe voeg vir elke kenmerk bykomend tot spesifiseer as dit primêre sleutel, vreemde sleutel, NULL toegelaat word, of die waarde daarvan is uniek. Deel 4 Implementering. 10 - Skryf DDL SQL-stellings om databasis, tafels en alle ander strukture te skep. Primêre sleutels en vreemde sleutels moet toepaslik gedefinieer. Die hoeveelheid beperkinge van die verhouding tussen die entiteite wat in Eerd diagram moet beskryf word, is nie nodig nie. 11- Gebruik die skep View verklaring aan die volgende aansigte te skep: Ek. Stock-simbool: Hierdie siening gee die Maatskappy Naam, maatskappy gestig Datum, Stock Kode, aantal aandele en Exchange name van alle voorraad simbole. 3 II. Hoë-sekuriteit: Hierdie siening terugkeer voorraad kode, laaste verhandelingsprys en huidige daaglikse volume vir elke simbool en opsie wat verlede verhandelingsprys is hoër as 100. iii. Goeie-Trader: Hierdie siening terug al die Trades wat ten minste 3 rekenings van ten minste 2 makelaars. iv. Stock-Verhandelde: Hierdie siening gee die naam vir maatskappy, voorraad en nommer van aandele is verhandel. v Popular-Trader:. Hierdie siening terugkeer diegene handelaars wat aandele verhandel meer as 1 van alle aandele verhandel. 12 - Verskaf SQL-stellings vir die volgende navrae. Voel vry om enige van die standpunte wat jy in deel (e) gebruik: vi. vii. viii. ix. x. XI. xii. xiii. xiv. XV. Vir elke openbare maatskappy lys van die aantal beurse wat sy voorraad ambagte op. Vind al Makelarye wat nie enige rekeninge het nie. Wys alle Effektebeurse wat voorraad het van die gevestigde openbare maatskappy voor 1 Januarie, 1980. Vind elke handelaar wat presies 'n rekening het. Vind alle bestellings wat reeds vervul deur ten minste 2 transaksies. Wys alle maatskappye waar die getal van sy verhandel aandele sy totale aantal aandele oorskry. Lys al die rekening van dié gewilde-Handelaars. Lys al die aandele wat deur Good-Handelaars geplaas bestellings. Wys alle transaksies ten volle sy twee bestellings vervul. Lys al die rekeninge wat limiet bestelling geplaas. 4 Studente gepos word 'n vraag middot 3 Junie 2010 by 12:40 pmProcessing lewendige mark data beslis verbruik geheue. As jy uit die geheue loop op 50 simbole, sou ek raai jou masjien is onder toegeruste vir wat jy probeer om te doen. Verwerking van handel gebeure en bestelboek diepte vir die ASX Alle oorde op die mees aktiewe dag in die laaste paar jaar (25-06-2013) verbruik ongeveer 8,3 GB geheue (sonder lopende enige metrieke analise). Ek sou aanbeveel loop hierdie soort analise op 'n masjien met ten minste 16GB RAM. Met betrekking tot wat jy vra, is daar 'n paar opsies wat beskikbaar is: 1) Neem net die mark kwotasie (boonste vlak van die bestelboek). Jy kan dit doen deur net die verwerking van die Spark. EVENTQUOTE gebeurtenis. 2) Hou 'n kleiner bestelboek deur ignoreer diepte updates buite 'n sekere prysvlak. Jy kan dit doen vergelyk die prys teen die huidige kwotasie prys, of deur te filter enigiets met 'n posisie indeks groter as 'n sekere drempel (bv 100). 3) Jy kan aftrek van die baan youve met die versoek om diepte met behulp van die API funksies soos GetStockDepthLevels voorgestel, maar jy in 'n stemdag model dan wat kom met sy eie probleme. Ek dink dit sal tot jou spesifieke behoeftes oor latency, versoek vrag, en wat die Spark API kan hanteer kom. Re: Spark Live Market Boek Diepte update. kash33 19-jul-15 00:38 Hi Paul, Thank you so much vir jou hulp. Ons het 'n uitsondering callbackoncollecteddelegate is bespeur 'n terugbel gemaak op 'n vullis ingesamel afgevaardigde van tipe SparkSparkLogCallback :: roep. Dit kan aansoek ineenstortings, korrupsie en die verlies van data veroorsaak. Wanneer verbygaande afgevaardigdes na onbeheerde kode, moet hulle gekoester word deur die bestuur aansoek totdat dit gewaarborg dat hulle nooit sal genoem word. Het jy hierdie fout teëgekom Ook, Dit is vreemd dat ons hou aan om NullReferenceException was verwerkte deur die gebruiker-kode - verwysing Object nie ingestel op versoek van 'n voorwerp en dit sê geen bron beskikbaar en ons weet nie wat lêer of lyn hierdie uitsondering veroorsaak. Sommige tye aansoek sal loop vir 'n uur voor die uitsondering is gegooi en 'n paar keer uitsondering sal in 2-5 minute gegooi. Gedink sal jou vra dit u enige kommentaar op hierdie. Re: Spark Live Market Boek Diepte update. kash33 5-Mei-15 09:26 Ons gebruik SparkAPI1.9.3. Die probleem wat ons het is vir 'n paar simbole soos AAK en FRE vir ASX ruil ons nie in staat is om bod kant dieptes kry waar dit 'n enkele of twee diepte vlakke. Ons is vas te lê securityOnDepthUpdate en ons gebruik AggregatedLimitOrderBook aggregateOrderBook nuwe AggregatedLimitOrderBook (order, DepthLevels) nou, is hierdie metode gedefinieer soos hieronder onder SparkApiSDKv1.2.0: - As jy kan kyk na bo kommentaar onderstreep, dit mis die eerste vlak en in die geval 'n voorraad het slegs enkele diepte vlak sal 'n leë Lys terugkeer. Kan jy bo kyk en laat my weet of dit is 'n fout Dankie vir al jou hulp. Re: Spark Live Market Boek Diepte update. Groot artikel.