The descriptive complexity approach to LOGCFL

Building upon the known generalized-quantifier-based first-order characterization of LOGCFL, we lay the groundwork for a deeper investigation. Specifically, we examine subclasses of LOGCFL arising from varying the arity and nesting of groupoidal quantifiers. Our work extends the elaborate theory relating monoidal quantifiers to NC1 and its subclasses. In the absence of the BIT predicate, we resolve the main issues: we show in particular that no single outermost unary groupoidal quantifier with FO can capture all the context-free languages, and we obtain the surprising result that a variant of Greibach's ``hardest context-free language'' is LOGCFL-complete under quantifier-free BIT-free projections. We then prove that FO with unary groupoidal quantifiers is strictly more expressive with the BIT predicate than without. Considering a particular groupoidal quantifier, we prove that first-order logic with majority of pairs is strictly more expressive than first-order with majority of individuals. As a technical tool of independent interest, we define the notion of an aperiodic nondeterministic finite automaton and prove that FO translations are precisely the mappings computed by single-valued aperiodic nondeterministic finite transducers.Comment: 10 pages, 1 figur

Positive Versions of Polynomial Time

AbstractWe show that restricting a number of characterizations of the complexity classPto be positive (in natural ways) results in the same class of (monotone) problems, which we denote byposP. By a well-known result of Razborov,posPis a proper subclass of the class of monotone problems inP. We exhibit complete problems forposPvia weak logical reductions, as we do for other logically defined classes of problems. Our work is a continuation of research undertaken by Grigni and Sipser, and subsequently Stewart; indeed, we introduce the notion of a positive deterministic Turing machine and consequently solve a problem posed by Grigni and Sipser

Hardness of approximation for quantum problems

The polynomial hierarchy plays a central role in classical complexity theory. Here, we define a quantum generalization of the polynomial hierarchy, and initiate its study. We show that not only are there natural complete problems for the second level of this quantum hierarchy, but that these problems are in fact hard to approximate. Using these techniques, we also obtain hardness of approximation for the class QCMA. Our approach is based on the use of dispersers, and is inspired by the classical results of Umans regarding hardness of approximation for the second level of the classical polynomial hierarchy [Umans, FOCS 1999]. The problems for which we prove hardness of approximation for include, among others, a quantum version of the Succinct Set Cover problem, and a variant of the local Hamiltonian problem with hybrid classical-quantum ground states.Comment: 21 pages, 1 figure, extended abstract appeared in Proceedings of the 39th International Colloquium on Automata, Languages and Programming (ICALP), pages 387-398, Springer, 201

Schemaevolution in objektorientierten Datenbanksystemen auf der Basis von Versionierungskonzepten

Gegenstand dieses Kapitels ist zunächst die Zusammenfassung der in dieser Arbeit erreichten Ergebnisse im Hinblick auf die ursprüngliche Zielsetzung, also die Unterstützung von Schema­ evolution in objektorientierten Datenbanksystemen. Anschließend folgen Überlegungen, welche der erzielten Ergebnisse zur Lösung von Problemen in anderen Arbeitsbereichen herangezogen werden können und auf welche Weise dies geschehen kann. Die Arbeit schlie?t mit einem Ausblick auf weitere Arbeiten im von uns bearbeiteten Themengebiet. Erreichte Ziele Ausgangspunkt unserer Arbeit war die Beobachtung, dass die Evolution von Datenbankschema­ ta, welche zur Anpassung an sich ändernde funktionale und nicht­funktionale Anforderungen 130 der Diskurswelt benötigt wird, durch die gegenwärtig verfügbaren Modelle und Systeme nicht adäquat unterstützt wird. Wir stellten daraufhin die Hypothese auf, dass ein Modell auf der Basis der Versionierung von Schemata mit einer entsprechenden Abbildung der Änderungen auf die Objektebene dies leisten kann. Wir konnten in dieser Abhandlung zeigen, dass das nach diesen Gesichtspunkten entworfene COAST­Modell die daran gestellten Erwartungen erfüllt und Sche­ maänderungen in Gegenwart existierender Objekte und Applikationen erfolgreich realisierbar sind. Die einzelnen Arbeitsschritte und Ergebnisse ergaben sich dabei wie folgt: - Problemanalyse und grober Modellentwurf: Die Notwendigkeit einer Unterstützung für Schemaevolutionsprozesse ergab sich aus der Beobachtung, dass vor allem moderne An­ wendungsbereiche eine flexible Anpassung an ständig veränderliche Umstände erfordern. Während des Betriebs einer Datenbank aufkommende Änderungsanforderungen lassen sich zur Entwurfszeit nicht vorhersehen und sind im Rahmen fest vorgegebener Datenbanksche­ mata nur schwerlich adäquat umsetzbar. Wir konnten in diesem Zusammenhang bei den vorhandenen Systemen zur Unterstützung der Schemaevolution das Fehlen einer Berück­ sichtigung im Betrieb beøndlicher Datenbankapplikationen feststellen. Gleichzeitig blieben Anforderungen an flexibel koppelbare Datenbankzustände für verschiedene Schemaausprä­ gungen bisher unberücksichtigt. Das an dieser Stelle grob skizzierte Modell zur Lösung des Problems beruhte folgerichtig auf dem Einsatz von Versionierungskonzepten auf der Ebene der Datenbankschemata. Solche Versionierungskonzepte hatten ihre Fähigkeiten zur Unterstützung von Evolutionsprozessen insbesondere auch im Zusammenhang mit Entwurfsaufgaben bereits zuvor sowohl auf der Ebene kompletter Datenbanken als auch auf der einzelner Objekte nachgewiesen. - Untersuchung bestehender Lösungsansätze: Wir konnten für das Lösungsmodell vier ele­ mentare Aspekte identiøzieren: Durchführung von Änderungen auf Schemaebene unter Verwendung von Versionierungskonzepten, Erzeugung und Verwaltung der Abhängigkeits­ beziehungen zwischen den Schemaversionen, Abbildung der Änderungen auf die Objekt­ ebene sowie flexible Konzepte zur Steuerung und Durchführung der Objektpropagation. Da kein Modell existierte, das all diese Punkte berücksichtigt, mussten wir uns in der Literatur­ recherche auf Ansätze beschränken, die sich mit einzelnen Aspekten unserer Aufgabenstel­ lung befassen. Aus dieser Perspektive stellt sich unser Modell zu einem Teil als Integration früherer Arbeiten dar. Zum anderen Teil beruht unser Modell in den grundlegenden Aspek­ ten der Behandlung von Ableitungsbeziehungen sowie der Steuerung und Durchführung der Objektpropagation auf gänzlich neuen Ansätzen. Die wesentliche Erkenntnis dieses Arbeitsschrittes ist somit die Feststellung, dass einerseits verschiedene Konzepte bestehen­ der Ansätze übernommen werden konnten, obwohl keine Arbeit alle Anforderungen an unser Modell erfüllte, und andererseits einige Aspekte bislang nahezu vollständig ignoriert wurden. - Detaillierte Modellbildung: Aufgrund der Erkenntnisse über bestehende Arbeiten entwarfen wir in diesem Arbeitsschritt COAST als Modell zur Durchführung von Schemaänderun­ gen in Anwesenheit von Objekten und Applikationen. Grundbestandteile unseres Ansatzes sind die Schemaversionen, die vergleichbar einer Konøgurationsverwaltung semantisch in Zusammenhang stehende Klassenversionen zu konsistenten Teilstrukturen zusammenset­ zen. Für die Durchführung von Schemaänderungen haben wir zwei grundsätzlich verschiedene Wege analysiert und resultierende Konsequenzen studiert. Dem internen Ansatz folgend wird eine von dem jeweiligen Einsatzgebiet des Systems unabhängige, fest vorgegebene und konzeptionell vollständige Taxonomie von Schemaänderungsprimitiven bereitgestellt, de­ ren Semantik a priori bekannt ist und demzufolge bei allen weiteren Schritten auf Schema­ und Objektebene berücksichtigt werden kann. Der externe Ansatz, als Alternative, erlaubt die Durchführung applikationsspezifischer Schemaänderungen und erhöht damit die Flexi­ bilität. Der Prozess des Einbringens extern erstellter Schemaversionen in das System kann dabei in vielfältiger Weise unterstützt werden. Bemerkenswerterweise fanden sich die auf Schemaebene angewandten Konzepte analog auf Instanzenebene wieder und zwar bei den Objektversionen, deren Zusammenhang sich in Form von Propagationsgraphen widerspiegelt ähnlich den Ableitungsbeziehungen auf Sche­ maebene. Die Steuerung der Objektpropagation sowohl zum Zeitpunkt der Schemaände­ rung als auch später, als Reaktion auf verändernde Datenbankzugrioee ist im behandelten Umfeld mit Sicherheit einzigartig. - Validierung des Modells: Aussagen zur Tauglichkeit des Modells im Hinblick auf seine Kon­ zeptionsziele konnten wir durch eine Evaluierung anhand unserer sehr detailliert beschrie­ benen Vorgaben erhalten. Damit ist gleichzeitig ein Vergleich mit bisherigen Lösungswegen insgesamt und mit einzelnen Vertretern davon gegeben. Die Evaluierung konnte in allen Aspekten belegen, dass das COAST­Modell zur Unterstützung von Schemaänderungen in Benutzung befindlicher Datenbanksysteme gut geeignet ist. Wir möchten an dieser Stelle nochmals betonen, dass COAST in vielerlei Hinsicht einfach erweitert werden kann und im Vergleich zu bisherigen Systemen durch erheblich flexiblere Möglichkeiten der Einflussnahme und eine verbesserte Tauglichkeit ausgezeichnet wird. Zu­ nächst sind sowohl die hier vorgestellte Schemaänderungstaxonomie als auch die damit ver­ bundene Propagationssprache vielfältig um komplexe Operationen erweiterbar. Weiterhin kann die Menge verwendbarer Propagationsflags insbesondere mit Blick auf das Verhalten bei komplexen Schemaänderungen hin ergänzt werden. Aber bereits die hier dargestell­ ten Möglichkeiten der Propagationssteuerung decken das gesamte Spektrum von isolierten Schemaversionen am einen Ende bis hin zur kompletten Propagation am anderen Ende ab. In Erweiterung der Konzepte auf der Basis von Sichtenmechanismen können durch die Objektversionierung beliebige Änderungen des Datenbankzustandes durchgeführt wer­ den. Damit wird ein erheblicher Beitrag für die Transparenz der Schemaevolution für die Applikationsentwickler geleistet. Die für die Tauglichkeit wichtigste Eigenschaft besteht zweifelsfrei in der Möglichkeit, be­ stehende Applikationen auch noch nach der Durchführung von Schemaänderungen ohne Anpassung weiterverwenden zu können. Damit erweitert sich der Einsatzbereich von Sche­ maänderungen auf sehr große, komponenten­basierte Systeme auf der Basis zahlreicher Einzelapplikationen. - Hinweise für den Datenbankentwurf: Um den Schemaversionierungmechanismus adäquat einsetzen zu können, erweisen sich Aussagen über den Schemaänderungsprozess als notwen­ dig. Daher haben wir diesen Prozess systematisch in Teilschritte zerlegt, die nacheinander betrachtet werden können. Bereits während der Modellbildung haben wir dort, wo sich ei­ nem Schemaentwickler Alternativen im Umgang mit COAST bieten, diese aufgezeigt und ihre jeweiligen Konsequenzen untersucht. Im Ergebnis resultiert für den Schemaentwick­ ler im Vergleich zu unversionierten Systemen ein zusätzlicher Spezifikationsaufwand. Dies ist jedoch für die Erreichung unserer Ziele unvermeidbar und der Gesamtaufwand für die Durchführung einer Schemaänderung reduziert sich dem Versionierungskonzept folgend er­ heblich, nicht zuletzt, weil aus der Sicht der Applikationsentwickler die volle Transparenz gewährleistet wird. - Realisierungsbetrachtungen: Um Erkenntnisse über den Realisierungsaufwand sowie die zu erwartenden Leistungsmerkmale zu erhalten, haben wir zweierlei Ansätze für eine pro­ totypische Realisierung untersucht. Zum einen haben wir einen Schemaversionierungsme­ chanismus als Aufsatz auf dem kommerziellen Objektdatenbanksystem O 2 implementiert. Auch wenn sich dies konzeptionell als möglich erwiesen hat, so haben sich dort an mehre­ ren Stellen erhebliche Einbußen bezüglich der Transparenz gezeigt [Wöh96]. Daher haben wir uns verstärkt mit dem zweiten, deutlich aufwendigeren Weg beschäftigt: die Eigenent­ wicklung eines kompletten, objektorientierten Datenbankmanagementsystems, bei dem die Konzepte von COAST transparent und von Anfang an im Kern integriert werden konnten. Die Realisierung der verzögerten Propagation kann bei realistischen Zugriffsprofilen mit einer gewissen Lokalität bezüglich der Schemaversionen größenordnungsmäßig mit unver­ sionierten Systemen vergleichbare Laufzeiten erreichen. Konzeptionell bedingt muss zwar ein größerer Platzbedarf als bei einem statischen System (ohne Schemaänderungen) in Kauf genommen werden. Im Vergleich zu anderen Konzepten der Schemaevolution, etwa den Ansätzen auf der Basis von isolierten Datenbanken oder mit materialisierten Sichten tritt aber kein Mehraufwand auf. In all diesen Varianten wird, ähnlich wie bei Puffern absichtlich Platz zugunsten einer erhöhten Zugriffsgeschwindigkeit investiert. Je ähnlicher sich verschiedene Schemaversionen sind und je intensiver die Propagation zwischen ihnen demnach ausfällt, desto besser sind die Voraussetzungen für platzsparende Mechanismen auf der Basis von mehreren Schemaversionen gemeinsam genutzter Objektversionen. In die­ sem Zusammenhang konnten wir eine Reihe von Verbesserungsmöglichkeiten identifizieren, die den COAST­Prototyp Systemen auf der Basis von Sichtenmechanismen gleichstellen würden. Übertragbarkeit der Ergebnisse Die Tragfähigkeit der Konzepte des COAST­Modells für die Unterstützung evolutionärer Sche­ maänderungen haben wir erfolgreich belegen können. Im folgenden sprechen wir noch einige Möglichkeiten an, die in dieser Abhandlung gewonnenen Erkenntnisse auch im Zusammenhang mit anderen Konzepten einzusetzen. - Abschnitt 2.2 hatte allgemeine Versionierungskonzepte vorgestellt, wie sie typischerweise auf Objekte angewendet werden, um deren inhaltliche Evolution abzubilden. Wir haben dieselben Konzepte in der vorliegenden Arbeit auf Schemata als Instanzen der Metaebene angewendet, um deren evolutionäre Entwicklung zu unterstützen. Dabei hat sich die Ver­ wendung versionierter Datenbankobjekte ebenfalls als sehr hilfreich erwiesen. Die Versio­ nen eines Objektes bei der Schemaversionierung repräsentieren ein Objekt in verschiedenen Datentypen. Von Situationen abgesehen, in denen das Modifikationsflag abgeschaltet ist und Änderungen daher gewollt nicht propagiert werden, repräsentieren die Versionen eines Objektes denselben logischen Objektwert. Damit unterscheiden sich die hier verwendeten Objektversionen von denen der klassischen Objektversionierung. Letztere stellen nämlich verschiedene logische Objektwerte dar, die allerdings alle demselben Datentyp entsprechen. Die vorangegangene, vergleichende Betrachtung zeigt einerseits, dass die beiden Formen der Versionierung unterschiedliche Ziele verfolgen, und andererseits legt sie die Vermutung nahe, dass es sich um orthogonale und damit gewinnbringend kombinierbare Ansätze han­ delt. Verschiedene Typen zur Darstellung desselben logischen Objektwertes hier stehen verschiedenen Objektwerten desselben Typs dort gegenüber. Tatsächlich lässt sich unser Ansatz um Mechanismen zur Objektversionierung erweitern, indem jede unserer Objektversionen nun durch verschiedene klassische Objektversionen ersetzt wird. Damit entsteht ein zweidimensionaler Raum von Objektversionen: entlang der einen Dimension liegt jeweils ein logischer Objektwert in verschiedenen Typen, entlang der anderen Dimension liegen jeweils verschiedene logische Zustände eines Objektes, die durch denselben Typ repräsentiert werden. Um die Kombination der beiden Versionierungskonzepte zu erreichen, sind allerdings noch einige Fragen näher zu untersuchen. Diese beschäftigen sich beispielsweise mit dem Zu­ sammenhang zwischen den Objektversionen entlang der beiden Dimensionen und mit der Propagation versionierter Objekte. Hier ist beispielsweise zu klären, ob alle, oder wenn nicht welche der logischen Objektwerte eines Objektes in andere Schemaversionen zu pro­ pagieren sind. Schließlich bietet die Realisierung des integrierten Gesamtkonzeptes zahl­ reiche Ansatzpunkte für technische Optimierungen und erfordert diese auch, um sowohl den Zeitaufwand für die Propagation als auch den Platzbedarf für die Speicherung der zweidimensional versionierten Objekte zu reduzieren. - Wir waren in der Literaturrecherche auf das Sichtenkonzept als Grundlage zur Simulati­ on von Schemaänderungen eingegangen und hatten dabei einige Deøzite bei der Lösung der hier betrachteten Aufgabenstellung identiøziert. Dies impliziert jedoch keine Aussa­ ge über die Tragfähigkeit von Sichten in dem Umfeld, für das sie ursprünglich konzipiert worden waren. Aufgrund der mit COAST erzielten Transparenz, die eine Schemaversion nach außen hin wie ein Schema eines unversionierten Systems erscheinen läßt, kann ein Sichtenkonzept auf dem COAST­Modell aufgesetzt werden. Konzeptionelle Schwierigkei­ ten sind durch die Kombination von Sichten und Schemaversionen nicht zu erwarten: Beim Ableiten neuer Schemaversionen können auf den Vorgängern definierte Sichten bei Bedarf mitintegriert werden und das Anlegen, Ändern und Löschen von Sichten kann durch die Primitive des Sichtenmechanismus erfolgen. In einem beide Konzepte integrierenden System kann entsprechend der gestellten Anforderungen entschieden werden, ob diese besser durch Anlegen einer neuen Sicht oder durch Ableiten einer neuen Schemaversion erfüllt werden. - Einen Schritt über die Integration eines separaten Sichtensystems hinaus geht die Über­ legung, ob Sichten nicht sogar durch Schemaversionen simuliert werden können. Damit wäre dann auch eine vollständig homogene Integration beider Konzepte in einem System erreicht. Um diese Überlegung zu verfolgen, betrachten wir die konzeptionellen Kompo­ nenten eines Sichtensystems und analysieren kurz, wie diese auf die Konzepte von COAST abgebildet werden können. Die für den Schemaentwickler zu verwendende Schnittstelle eines Sichtensystems ist durch die Sichtendefinitionssprache gegeben. Die dort zur Verfügung stehenden Konstrukte die­ nen zunächst der Definition des Sichtschemas und sind insoweit durch die Primitive der COAST­ODL abgedeckt. Darüber hinaus bestimmt eine Sichtendefinition die Extension der Sichtklassen durch Angabe je einer Anfrage, wobei das Ergebnis dieser Anfrage dem Schema der definierten Sichtklasse entsprechen muss bzw. dieses implizit erst bestimmt. Um diesen Teil eines Sichtenkonzeptes zu simulieren, sind in COAST zwei Erweiterungen not­ wendig. Zum einen wird eine Anfragesprache benötigt. Diese wäre für die Vervollständigung von COAST sowieso erforderlich und könnte sich konzeptionell sehr stark an bestehenden objektorientierten Anfragesprachen orientieren. Ein Anfragesystem muss zu jeder Anfrage zunächst das Schema ihres Resultates ermitteln und dieses könnte dann mit den Primiti­ ven der COAST­ODL erstellt werden. Daraufhin muss das Anfragesystem die eigentliche Durchführung der Anfrage auf der Datenbank erledigen. Dies beschreibt gleichzeitig die zweite in COAST erforderliche Erweiterung. Für die Durchführung der Anfrage und ins­ besondere der darin ggf. enthaltenen Selektion von Objekten müsste eine entsprechende Erweiterung der Propagationssprache von COAST vorgenommen werden. Änderungen von Objekten in Sichtklassen sind aufgrund des Sichtenänderungsproblems i.Allg. nicht durchführbar, da in der Sichtendefinitionssprache keine Möglichkeit besteht, die Auswirkungen einer solchen Änderung auf die Objekte des Basisschemas zu spezifi­ zieren. Daher bieten einige Konzepte Erweiterungen an, die man in COAST durch Ver­ wendung von Rückwärtskonvertierungsfunktionen bereits hat. Durch die Vorwärts­ und Rückwärtskonvertierungsfunktionen können beide Richtungen von Abbildungen zwischen (simuliertem) Basisschema und (simuliertem) Sichtschema sogar homogen durch dasselbe Konzept spezifiziert werden. Die Propagationsflags wären zur Simulation alle eingeschaltet und durch die Verwendung der verzögerten Propagationsmechanismen von COAST liefert die Simulation von Sich­ ten durch Schemaversionen zusätzlich ein optimiertes Konzept der Materialisierung von Sichten. - Das Konzept der direkten Schemaevolution hatte sich bei der Anwendung in dem hier beschriebenen Einsatzgebiet als zu restriktiv erwiesen. Nichtsdestotrotz kann die direkte Schemaevolution in Einzelfällen für die Durchführung von Schemaänderungen genügen, insbesondere solange noch keine Applikationen für eine Schemaversion implementiert sind. Folgerichtig können Situationen entstehen, wo selbst eingefrorene Schemaversionen noch in eingeschränktem Umfang änderbar wären, auch wenn dies i.Allg. nicht der Fall ist. Daher haben wir eine Kombination der direkten Schemaänderung mit dem Versionierungsansatz auf der Basis des Datenmodells von O 2 untersucht [FL96] (siehe Abschnitt 5.4.2). Dort konnten wir durch eine Klassiøkation der Schemaänderungsprimitive feststellen, ob den im Einzelfall gegebenen Umständen zufolge die Ableitung einer neuen Schemaversion erfor­ derlich ist oder nicht. Auf diesem Wege kann die Zahl entstehender Schemaversionen und damit auch der sich ergebende Verwaltungsaufwand reduziert werden. - Die in Datenbanksystemen benötigten Änderungsoperationen lassen sich drei elementaren Kategorien zuordnen

The GOODSTEP project: General Object-Oriented Database for Software Engineering Processes

The goal of the GOODSTEP project is to enhance and improve the functionality of a fully object-oriented database management system to yield a platform suited for applications such as software development environments (SDEs). The baseline of the project is the O2 database management system (DBMS). The O2 DBMS already includes many of the features regulated by SDEs. The project has identified enhancements to O2 in order to make it a real software engineering DBMS. These enhancements are essentially upgrades of the existing O2 functionality, and hence require relatively easy extensions to the O2 system. They have been developed in the early stages of the project and are now exploited and validated by a number of software engineering tools built on top of the enhanced O2 DBMS. To ease tool construction, the GOODSTEP platform encompasses tool generation capabilities which allow for generation of integrated graphical and textual tools from high-level specifications. In addition, the GOODSTEP platform provides a software process toolset which enables modeling, analysis and enaction of software processes and is also built on top of the extended O2 database. The GOODSTEP platform is to be validated using two CASE studies carried out to develop an airline application and a business application

Computational complexity of the landscape I

We study the computational complexity of the physical problem of finding vacua of string theory which agree with data, such as the cosmological constant, and show that such problems are typically NP hard. In particular, we prove that in the Bousso-Polchinski model, the problem is NP complete. We discuss the issues this raises and the possibility that, even if we were to find compelling evidence that some vacuum of string theory describes our universe, we might never be able to find that vacuum explicitly. In a companion paper, we apply this point of view to the question of how early cosmology might select a vacuum.Comment: JHEP3 Latex, 53 pp, 2 .eps figure

On Second-Order Monadic Monoidal and Groupoidal Quantifiers

We study logics defined in terms of second-order monadic monoidal and groupoidal quantifiers. These are generalized quantifiers defined by monoid and groupoid word-problems, equivalently, by regular and context-free languages. We give a computational classification of the expressive power of these logics over strings with varying built-in predicates. In particular, we show that ATIME(n) can be logically characterized in terms of second-order monadic monoidal quantifiers