SQL-basierte Stellungsanalyse im Schach: eine IDB-Fallstudie

Transkript

1 Fallstudie Schachspiel Intelligente Datenbanken SS 20 SQL-basierte Stellungsanalyse im Schach: eine IDB-Fallstudie - Kapitel 2-20 Prof. Dr. R. Manthey

2 "Schachspielen in in SQL"? SQL"? in diesem pragmatischen Zwischenkapitel: Diskussion eines weiteren Modellierungs- beispiels einer "realen" Anwendung Schachregeln in in SQL SQL Wieso sind die Regeln des Schachspiels ein (intelligentes) DB-Thema? Schach ist seit langem ein aktives Anwendungsgebiet verschiedenster Informatik-Techniken. populär: Schachspielprogramme ("Deep Blue") Forschungsthema u.a. in der KI, Spieltheorie und Algorithmik zentrale Rolle: Datenbanken mit Partien (z.b. von Großmeistern auf internationalen Turnieren) Stellungen (mit Fortsetzungsmöglichkeiten), insbesondere Eröffnungen und Endspiele (z.b. alle 5-Steiner: ca. 2 Giga-Byte!) Schachdatenbanken erheblichen Umfangs (z.b.,6 Mill. Partien) sind kommerziell über Internet oder auf CD-ROM verfügbar bisher: "Schach-DB" sind reine Faktensammlungen (oft komprimiert) mit speziellen Schnittstellen selten: Verwendung eines DBMS nie (?): regelbasierte Techniken 20 Prof. Dr. R. Manthey 2

3 Regeln Regeln in in Schach-DB: : Ideen Ideen und und Spekulationen am naheliegendsten: Spielregeln als DB-Regeln normativ: zulässige Zugfolgen (dynamische IB) und Stellungen (statische IB) deduktiv: Definitionen von Schach-Begriffen (z.b. matt, remis, gedeckt, gefesselt) und der legalen Zugmöglichkeiten aktiv: Lehr- und Trainingssysteme, Überprüfung "dynamischer" Spielregeln (Remisreklamation nach 50 Zügen, Bauernumwandlung) weitere Einsatzmöglichkeiten deduktiver Regeln: Bewertung und Analyse von Stellungen Herleiten von Stellungen aus Zugfolgen Empfehlungen für aussichtsreiche Folgezüge (Strategien) ebenfalls aussichtsreich: "Data Mining" in Schach-DB (zur Gewinnung strategischen Wissens: Assoziationsregeln) All diese Möglichkeiten wurden bisher (meines Wissens) nicht genutzt Die folgende Beispielmodellierung diente als Grundlage für eine entsprechende Fallstudie in einer einschlägigen Diplomarbeit in meiner Gruppe (999), fortgesetzt in einer weiteren DA Themen in dieser Richtung sind noch verfügbar! 20 Prof. Dr. R. Manthey 3

4 Deduktive Datenbank zur zur Stellungsanalyse im im Schach Schach in diesem Kapitel: Modellierung des Schachspiels zum Zweck des Aufbaus eines DB-basierten Systems zur intelligenten Analyse von Schachstellungen Zulässigkeit von Zügen Erkennen spezieller Situationen (Schach, Bedrohung, Fesselung) Ermitteln der Konsequenzen bestimmter Züge in aktueller Stellung kein Abspeichern oder Bewerten von Spielzügen Analyse Fakten Regeln 20 Prof. Dr. R. Manthey 4

5 Stellungsanalyse in in SQL: SQL: Motivation gefesselt zu zu trainierende Fähigkeit: F Lerne Lerne deduktiv Denken und und Modellieren! a b c d e f g h gedeckt_von bedroht_durch im_schach Ultimatives Ultimatives Ziel : Ziel : Schach Schach und und Matt Matt erkennen erkennen können! kkönnen! (setzt (setzt alle alle anderen anderen Analyse- Analysefähigkeiten voraus) fähigkeiten voraus) 20 Prof. Dr. R. Manthey Intelligente DB 5

6 Schach Schach Grundkonzepte Ein Spieler steht im Schach, wenn sein König von irgendeiner gegnerischen Figur bedroht wird! Fachtermini a b c d e f g h Idee einer zugehörigen Analysesicht: Welche Figuren stehen im Schach? CREATE VIEW VIEW im_schach Prof. Dr. R. Manthey 6

7 Doppelschach Ein Spieler steht im Doppelschach, wenn sein König von zwei gegnerischen Figuren gleichzeitig bedroht wird! (Schlagen eines Angreifers oder Abblocken eines Angriffs hilft dann nicht mehr!) CREATE VIEW VIEW im_doppelschach.... schon hier erkennbar: Wir folgen einer Top-Down-Entwurfsstrategie! Gehe von den Zielkonzepten aus und definiere zuerst nur die Sichtnamen! Bestimme dann die benötigten Unterkonzepte und beginne danach erst zu programmieren! 20 Prof. Dr. R. Manthey 7

8 Matt Matt Ein Spieler ist Matt, wenn sein König im Schach steht und wenn das Schach nicht durch Abziehen des Königs oder durch Züge anderer Figuren des Angegriffenen abwendbar ist! CREATE VIEW VIEW ist_matt ist_matt..... Alle Felder, die der schwarze König K erreichen könnte, sind von weiß bedroht. 2. Der schwarze Turm kann kein Schach abblocken. 3. Die schwarze Dame kann kein Schach verhindern. 20 Prof. Dr. R. Manthey 8

9 Schach Schach und und Matt: Matt: Übersicht König beweglich einfaches Schach König nicht beweglich Angreifer schlagbar Schach abblockbar Schach abwendbar Schach sonst MATT MATT Doppelschach König beweglich König nicht beweglich Schach abwendbar MATT MATT 20 Prof. Dr. R. Manthey 9

10 Modellierung des des Schachbretts und und der der Figuren Figuren Bevor Bevor es es mit mit dem dem Top Top-Down-Spezifizieren losgehen losgehen kann, kann,.... sollte sollte zumindest zumindest klar klar sein, sein, was was bottom bottom wirklich wirklich heißt! heißt! daher zunächst: Bereitstellen der "Infrastruktur", d.h. Modellieren des Schachbretts und der einzelnen Figurenpositionen als DB-Fakten? a b c d e f g h 20 Prof. Dr. R. Manthey 0

11 Schachbrett mit mit Koordinatensystem Y Reihen Feld mit Koordinaten (d,4) a b c d e f g h Wie beim Game of Life ist die Schachwelt als 2D-Matrix aus Zellen aufgebaut. Ein sequentielles Durchnummerieren der Zellen wäre möglich, ist aber im Schach völlig unüblich. X-Koordinate als Buchstabe und Y-Koordinate als Zahl ist Standardnotation! Linien X 20 Prof. Dr. R. Manthey

12 Steine Steine und und Farben Farben a b c d e f g h Es gibt 6 verschiedene Typen von Schachfiguren (auch Steine genannt), für die wir jeweils den ersten Buchstaben als Code verwenden werden: König König Dame Dame Turm Turm Läufer Läufer Springer Springer Bauer Bauer kk dd tt ll ss bb Es gibt zwei Spieler, die durch die Farben der Steine unterschieden werden: Jeder Figurentyp ist also durch ein Codepaar identifiziert, z.b.: (k,w) für den weißen König. weiß weiß schwarz schwarz w ss 20 Prof. Dr. R. Manthey 2

13 Positionen von von Figuren Figuren auf auf dem dem Brett Brett a b c d e f g h Jede Schachstellung kann damit in einer Tabelle mit vier Spalten gespeichert werden, im Bsp.: position Figur Farbe X Y k w f l w e 2 b w c 3 k s c 8 d s b 5 b s g 7 (Das zugehörige Schema sollte offensichtlich sein.) 20 Prof. Dr. R. Manthey 3

14 Schach Schach Ein Spieler steht im Schach, wenn sein König von irgendeiner gegnerischen Figur bedroht wird! CREATE VIEW VIEW im_schach (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K K.Figur K.Figur = 'k' 'k' EXISTS (SELECT a b c d e f g h * FROM FROM position position A benötigt: Sicht, die feststellt, ob eine K.Farbe K.Farbe < > A.Farbe A.Farbe Figur von einer anderen....).) bedroht wird! dazu erforderlich: Wie können k Figuren ziehen? 20 Prof. Dr. R. Manthey 4

15 Bedrohung und und Zugmöglichkeiten glichkeiten Figur kann Figur 2 nur dann bedrohen, wenn beide unterschiedliche Farbe haben. Ist das bereits sichergestellt (wie in unserem Schachkontext ), dann reicht aus, dass die eine Figur (der Angreifer) von ihrer Position die Position der anderen Figur (dem Opfer) aus erreichen kann (und zwar durch einen Zug). Um bedroht zu spezifizieren, muss man also analysieren, wer wohin ziehen kann! 20 Prof. Dr. R. Manthey 5

16 Zugmöglichkeiten glichkeiten des des LäufersL Läufer können aber verdeckte Felder nicht erreichen. Läufer können diagonal im Prinzip beliebig weit ziehen. 20 Prof. Dr. R. Manthey 6

17 Zugmöglichkeiten glichkeiten des des Turms Turms Auch für Türme können Felder verdeckt sein. Türme ziehen rechtwinklig. 20 Prof. Dr. R. Manthey 7

18 Zugmöglichkeiten glichkeiten der der Dame Dame Verdeckung von Feldern für Damen leitet sich aus der für Türme und Läufer ab. Damen ziehen rechtwinklig wie Türme oder diagonal wie Läufer. 20 Prof. Dr. R. Manthey 8

19 Zugmöglichkeiten glichkeiten des des Springers Springer können durch eigene oder gegnerische Figuren nicht "aufgehalten" werden ("überspringen" sie). Springerzüge bereiten gerade Anfängern leicht Schwierigkeiten: "Rösselsprung" 20 Prof. Dr. R. Manthey 9

20 Zugmöglichkeiten glichkeiten des des Bauern Bauern () () Ausnahme: Im ersten Zug (aus der Ausgangsposition) ist alternativ auch ein Doppelschritt erlaubt. Das Grundprinzip der Züge von Bauern ist denkbar einfach: Bauern bleiben in "ihren" Linien und gehen pro Zug eine Reihe "vorwärts" Prof. Dr. R. Manthey 20

21 Zugmöglichkeiten glichkeiten des des Bauern Bauern (2) (2) zusätzlich: Zwischenfeld bei Doppelschritt darf nicht blockiert sein (und Zielfeld natürlich frei). Bauern dürfen ihr direktes Nachbarfeld in Laufrichtung nur dann besetzen, wenn es nicht durch eine Figur besetzt ist. (Kein Schlagen des Gegners möglich!!) 20 Prof. Dr. R. Manthey 2

22 Zugmöglichkeiten glichkeiten des des Bauern Bauern (3) (3) Besonderheit beim Doppelschritt: en passant -Schlagen (dt.: im Vorübergehen bergehen ) aber: Ein vom Gegner besetztes Diagonalfeld kann (mit Schlagen) betreten werden. (von Wikipedia) 20 Prof. Dr. R. Manthey 22

23 Zugmöglichkeiten glichkeiten des des KönigsK Könige können (im Prinzip) jedes direkte Nachbarfeld erreichen: Ausnahme : Könige dürfen d nie ein vom Gegner bedrohtes Feld betreten! (Jede andere Figur hingegen darf "sich opfern"!) Ausnahme 2: Ein angegriffener König K darf ein Nachbarfeld nicht betreten, wenn er dort (vom selben Angreifer) nach dem Wegziehen immer noch bedroht wäre. w ( Rochade soll hier außen vor bleiben.) 20 Prof. Dr. R. Manthey 23

24 SQL-Spezifikation Spezifikation von von Erreichbarkeit von von Feldern Feldern durch durch Figuren Figuren a b c d e f g h Läufer können diagonal im Prinzip beliebig weit ziehen. Wie Wie drückt drückt man man diagonal aus? aus? Exemplarisch am Beispiel des Läufers Sicht zur Erreichbarkeitsanalyse: (zuerst ohne Berücksichtigung von Verdeckung) CREATE VIEW VIEW erreichbar_.... erreichbar_ Figur FX FY X Y l c 3 a l c 3 b 2 l c 3 d 2 l c 3 e l c Erreichbarkeit ist figurenabhängig ngig: Ein Springer würde w von (c,3) aus andere Felder erreichen! 20 Prof. Dr. R. Manthey 24

25 Positionendarstellung revidiert a b c d e f g h Um besser mit Feldkoordinaten rechnen zu können, soll doch lieber dieselbe numerische Koordinatendarstellung gewählt werden wie bei GoL: position Figur Farbe X Y k w 6 l w 5 2 b w 3 3 k s 3 8 d s 2 5 b s 7 7 (Das zugehörige Schema sollte offensichtlich sein.) 20 Prof. Dr. R. Manthey 25

26 Diagonale Erreichbarkeit Jetzt kann man die Diagonalen ausrechnen, aber wie macht man das? Muskellösung : sung : Alle Alle Diagonalpaare vorausberechnet abspeichern! diagonal VonX VonY NachX NachY Der Startpunkt kann beliebig sein, aber an den Grenzen des Spielfelds muss Schluss sein. Welcher View steckt dahinter? 20 Prof. Dr. R. Manthey 26

27 Erreichbarkeit für ffür r Läufer LLäufer (ohne (ohne Verdeckung) CREATE VIEW VIEW erreichbar_ (SELECT P.Figur,, P.X P.X FX, FX, P.Y P.Y FY, FY, D.NachX X, X, D.NachY Y FROM FROM position position P JOIN JOIN diagonal D ON ON P.X=D.VonX P.Y=D.VonY P.Figur='l' ' ) ) UNION UNION.... andere Figuren Läufer position Figur Farbe X Y l w 3 3 diagonal VonX VonY NachX NachY erreichbar_ Figur FX FY X Y l 3 3 l Prof. Dr. R. Manthey 27

28 Erreichbarkeit für ffür r Läufer LLäufer mit mit Verdeckung? CREATE CREATE VIEW VIEW erreichbar_ erreichbar_ (SELECT (SELECT P.Figur, P.Figur,, P.X P.X FX, FX, P.Y P.Y FY, FY, D.NachX D.NachX X, X, D.NachY D.NachY Y FROM FROM position position P P JOIN JOIN diagonal diagonal D ON ON P.X=D.VonX P.X=D.VonX P.Y=D.VonY P.Y=D.VonY P.Figur='l' P.Figur='l' ' ) ) UNION UNION.... Wenn man durch eine Sicht verdeckt auch verdeckte Felder bestimmen kann,... (relativ zu einem bestimmten Blickpunkt und einem Figurentyp) Läufer können verdeckte Felder nicht erreichen. CREATE CREATE VIEW VIEW erreichbar erreichbar ((SELECT ((SELECT 'l' 'l' Figur, Figur, FX, FX, FY, FY, X, X, Y FROM FROM erreichbar_ erreichbar_ ) ) MINUS MINUS (SELECT (SELECT 'l' 'l' Figur, Figur, FX, FX, FY, FY, X, X, Y FROM FROM verdeckt)) verdeckt)) UNION UNION.... (FX,FY) (X,Y) 20 Prof. Dr. R. Manthey 28

29 Schach-Spezifikation Spezifikation Reloaded CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K K.Figur K.Figur = 'k' 'k' EXISTS EXISTS (SELECT (SELECT * * FROM FROM position position A K.Farbe K.Farbe < > A.Farbe A.Farbe....) ) Hier fehlt noch die Bedingung, dass die Figur auf Position A den König auf Position K erreichen kann (also bedroht)! Eine einfache Verknüpfung mit erreichbar leistet das, aber schön ist s nicht:.... EXISTS EXISTS (SELECT (SELECT* * FROM FROM erreichbar erreichbar A.Figur=Figur A.Figur=Figur A.X=FX A.X=FX A.Y=FY A.Y=FY K.X=X K.X=X K.Y=Y K.Y=Y ) ) CREATE CREATE VIEW VIEW erreichbar erreichbar ((SELECT ((SELECT Figur, Figur, FX, FX, FY, FY, X, X, Y FROM FROM Prof. Dr. R. Manthey 29

30 Schach-Spezifikation Spezifikation Reloaded (2) (2) CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K K.Figur K.Figur = = 'k' 'k' EXISTS EXISTS (SELECT (SELECT * * FROM FROM position position A K.Farbe K.Farbe < < > > A.Farbe A.Farbe EXISTS EXISTS (SELECT (SELECT * * FROM FROM erreichbar erreichbar A.Figur=Figur A.Figur=Figur A.X=FX A.X=FX A.Y=FY A.Y=FY K.X=X K.X=X K.Y=Y K.Y=Y )) )) Zusammenfalten der verschachtelten Unteranfragen macht die Spezifikation wieder lesbarer, zumindest etwas: CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K, K, erreichbar erreichbar E, E, position position A K.Figur K.Figur = = 'k' 'k' K.Farbe K.Farbe < < > > A.Farbe A.Farbe A.Figur A.Figur = = E.Figur E.Figur A.X A.X = = E.FX E.FX A.Y A.Y = = E.FY E.FY K.X K.X = = E.X E.X K.Y K.Y = = E.Y E.Y ) ) 20 Prof. Dr. R. Manthey 30

31 Schach-Spezifikation Spezifikation Reloaded (3) (3) CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K, K, erreichbar erreichbar E, E, position position A K.Figur K.Figur = = 'k' 'k' K.Farbe K.Farbe < < > > A.Farbe A.Farbe A.Figur A.Figur = = E.Figur E.Figur A.X A.X = = E.FX E.FX A.Y A.Y = = E.FY E.FY K.X K.X = = E.X E.X K.Y K.Y = = E.Y E.Y ) ) Kann man diese Formulierung denn nicht noch intuitiver lesbar machen, indem man die Logik der natürlichsprachlichen Definition erkennbar macht? Ein Spieler steht im Schach, wenn sein König K von irgendeiner gegnerischen Figur bedroht wird! ( das Feld des Königs K von gegnerischer Figur erreichbar, die auch wirklich auf dem Brett steht ) CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K, K, bedroht bedroht B.... ) ) CREATE CREATE VIEW VIEW bedroht bedroht (SELECT (SELECT.... FROM FROM ) ) 20 Prof. Dr. R. Manthey 3

32 Schach-Spezifikation Spezifikation Reloaded (4) (4) So könnte es gehen, wenn man die Struktur der natürlichsprachlichen Formulierung durch Verwendung einer speziellen Sicht simuliert : CREATE CREATE VIEW VIEW im_schach im_schach (SELECT (SELECT K.Farbe K.Farbe Spieler Spieler FROM FROM position position K, K, K.Figur K.Figur = = 'k' 'k' EXISTS EXISTS (SELECT (SELECT * * FROM FROM bedroht bedroht A K.X= K.X= A.X A.X K.Y K.Y = = A.Y A.Y K.Farbe K.Farbe < < > > K.Farbe) K.Farbe) CREATE CREATE VIEW VIEW bedroht bedroht (X, (X, Y, Y, Farbe) Farbe) (SELECT (SELECT E.X, E.X, E.Y, E.Y, A.Farbe A.Farbe FROM FROM position position A, A, erreichbar erreichbar E, E, A.Figur A.Figur = = E.Figur E.Figur A.X A.X = = E.FX E.FX A.Y A.Y = = E.FY) E.FY) Nach außen interessiert weder, welche Figur angreift, noch wo sie steht, sondern nur das Zielfeld und die Farbe des Angreifers. Ein Spieler steht im Schach, wenn sein König K von irgendeiner gegnerischen Figur bedroht wird! 20 Prof. Dr. R. Manthey 32

33 Zwischenbilanz Um Matt spezifizieren zu können, k müsste man jetzt noch Konzepte wie Fesselung spezifizieren! Viel haben wir noch gar nicht erreicht, aber die Komplexität der Aufgabe wird sicher schon deutlich! gefesselt Wer mag, kann sich am Weiterentwickeln beteiligen Matt zu spezifizieren, wäre ein schönes nächstes Ziel! Auch diagonal ist noch offen Prof. Dr. R. Manthey 33