Die Datenbank-Spezialisten. Datenbanken. eine starke Basis für Produktentwicklungen

Transkript

1 Datenbanken eine starke Basis für Produktentwicklungen Björn Heinemann,

2 Agenda Vorstellung Architektur von Softwaresystemen Geschäftslogik in der Datenbank Beispiel Energiedatenmanagement

3 Zahlen und Fakten Robotron Datenbank-Software GmbH Gründungsjahr 1990 Geschäftsform GmbH (9 Gesellschafter) Mitarbeiterzahl 349 (Stand 01/2015) Stammkapital Umsatz 2013 Umsatz ,4 Mio. EUR 31,1 Mio. EUR 31,2 Mio. EUR Hauptsitz Oracle-Partner ISO 9001 zertifiziert Kongress- und Schulungszentrum

4 Robotron-Firmengruppe Tschechien: Robotron Database Solutions s.r.o. Schweiz: Robotron Schweiz GmbH Österreich: Robotron Austria GmbH Russland: Robotron Rus GmbH Deutschland: Robotron ECG solutions GmbH Deutschland: SASKIA Informations-Systeme GmbH

5 Unsere Wurzeln

6 Unsere Kernkompetenz

7 Softwareentwicklung mit Datenbanken Energiedatenmanagement Systeme robotron*ecount, robotron*esales als Produkt seit 15 Jahren im Einsatz Museumsmanagement-System robotron*daphne eine Vielzahl von Projekten in Öffentlicher Verwaltung und Industrie

8 Referenzen national

9 Architektur von Softwaresystemen Wie wurde und wird Software aufgebaut? Einfach Anwendung Logik, Datenhaltung und Nutzerinteraktion in einem Block?

10 2 Schichten Architektur komplexere Anwendungen Trennung der Datenhaltung von der Benutzeroberfläche typischerweise thick clients der 80er/90er Jahre die Logik war oftmals im Client verschiedene Clientanwendungen mit wiederholter Logik Anwendung 1 Anwendung 2 Server Probleme: verteilte Logik hoher Wartungsaufwand komplexes Deployment in großen Umgebungen Anwendung 3

11 3 Schichten Architektur Einführung eines Applikationsservers Zusammenfassung der Logik in der Mittelschicht 3 Hauptbestandteile Datenhaltungsschicht Geschäftslogik in der Mittelschicht Benutzeroberfläche Vor- und Nachteile Schnelle Verarbeitung in der Mittelschicht Datentransfer zum DB-Server Caching mehrere Applikationsserver müssen synchronisiert werden einfaches Deployment bei Webanwendungen Applikationsserver Datenbank-Server

12 3 oder 2 Schichten? Trennung von Client und Geschäftslogik ist sinnvoll Betrachtung des Anwendungsfalles Anzahl der Nutzer Sessionmanagement Datenflüsse Prozesse Auslagerung von Teilprozessen auch mit 2 Schichten immer noch möglich Synchronisation aller Prozesse über die DB automatisch durch Transaktionsverwaltung Datenbank-Server

13 Logik in der Datenbank wie geht das? Relationale Ablage von Daten Entitäten mit Attributen und Relationen Moderne Datenbanken bieten umfassende Funktionalitäten Funktionen, Prozeduren und Packages Views, Trigger Jobsteuerung

14 Funktionen, Prozeduren & Packages Abbildung von Logik mit Hilfe von PLSQL strukturierte Programmierung alle Datentypen der DB nutzbar komplexe Recordtypen können definiert werden sofortiger Zugriff auf die Daten CREATE OR REPLACE FUNCTION FNC_GET_ENAME (P_EMPNO IN NUMBER) RETURN VARCHAR2 AS p_name EMP.ENAME%type; BEGIN select ENAME into p_name from EMP where EMPNO = p_empno; return p_name; END FNC_GET_ENAME; kann wieder im SQL verwendet werden SELECT FNC_GET_ENAME(7499) FROM DUAL; dynamisches SQL zur Laufzeit möglich unbedingt BIND Variablen verwenden

15 Trigger Mit Triggern kann auf DML direkt reagiert werden Nutzung unter anderem zur Datenvervollständigung, Protokollierung, Abgleich (Master/Detail) INSERT, UPDATE, DELETE können speziell behandelt werden ROW bzw. STATEMENT Level ROW feuert für jedes Tupel STATEMENT wird einmal für das Statement ausgeführt egal wie viele Tupel betroffen sind Kombination möglich ROW-Level Daten in Package Variablen Sammeln im STATEMENT Trigger verarbeiten

16 Views Definition von speziell ausgeprägten Sichten virtuelle Relationen Abbildung komplexer Abfragen vereinfachte Sicht Umsetzung von Zugriffsrechten Nutzer erhält nur SELECT Recht an VIEW nicht an Tabelle unter Beachtung bestimmter Voraussetzungen kann DML auf VIEWs angewendet werden

17 Views Filterung von Attributen Ausblenden der Gehaltsinformationen CREATE OR REPLACE VIEW V_EMP AS select EMPNO, ENAME, JOB, MGR, DEPTNO from EMP; GRANT SELECT ON V_EMP TO BHEINEMANN; Filterung von Tupeln Filterung auf alle Mitarbeiter DEPT 20 CREATE OR REPLACE VIEW V_EMP2 AS select EMPNO, ENAME, JOB, MGR from EMP where DEPTNO=20; GRANT SELECT ON V_EMP2 TO BHEINEMANN;

18 Jobs umfangreiche Prozesssteuerung innerhalb der Datenbank Zeit- und ereignisgesteuert Protokollierung Einbettung in Wartungs- und Backupzyklen Parallelisierung breite Werkzeugunterstützung aber auch APIs nutzbar

19 Datenbank Funktionen Funktionsvielfalt von SQL Aggregation Sortierung Gruppierung geschickte Nutzung von PL/SQL und SQL gemeinsam Package Variablen Speicherung von Zuständen während der Session pipelined Funktionen -> Views komplexe Programmlogik zur Bereitstellung von Datenstrukturen diese wieder im SQL nutzbar funktionsbasierte Indices virtual private database Abbildung von Mandanten XML Verarbeitung keine Massendaten Nachrichten Umfangreiche APIs mitgeliefert (TCP/IP, HTTP, )

20 Datenbank Funktionalitäten Performance Packages werden nicht pur interpretiert vorkompilierter Kode (MCode) wird in DB abgelegt zur Laufzeit Ausführung des vorkompilierten Kodes alternativ native compiled Kode in der DB Kode der Packages, Funktionen und Prozeduren wird direkt in Maschinenkode übersetzt schnellere Ausführung längere Übersetzungszeit alter session set plsql_code_type='native'; alter package pkg_apex_intern compile;

21 Datenbank Funktionalitäten Performance Sind die Abfragen performant? Ausführungspläne beachten... SELECT * from emp e where E.DEPTNO in (select D.DEPTNO from dept d where D.LOC = 'DALLAS') Index auf FK DEPNO fehlt Index angelegt damit kein FULL TABLE SCAN

22 Datenbank Funktionalitäten Performance SQL-Trace kann auch zur Laufzeit aktiviert werden Analyse von Performance-Problemen auf produktiven Systemen Performance Analyse im PL/SQL Kode mit Hilfe des Profilers analysiert und visualisiert die Laufzeiten des Programmkodes PL/SQL Kode kann debuggt werden zusätzliche Privilegien erforderlich, gute Werkzeugunterstützung

23 Vorteile einer umfangreichen Datenbanknutzung minimale Latenzzeiten zwischen dem Lesen/Schreiben und dem Verarbeiten der Daten leichtere Wartung Datenmodell und Logik passen zusammen weniger Schnittstellen Parallelisierung durch die DB selbst langfristiger Betrieb wie stabil ist eine Plattform ist die Architektur auch in Zukunft verständlich

24 Beispiel Energiedatenmanagement

25 Systemarchitektur Welche Funktionen bzw. Prozessbausteine sind beteiligt EDM System CRM, Stammdatenhaltung Abrechnungssystem Portfolio- und Fahrplanmanagement / Nominierungsmanagement Gerätemanagement Zählerfernauslesung (klassische RLM Zähler und neue Smart Meter ) Prognose Kommunikationsplattform (EDIFACT Kommunikation) Kommunikationswege ( , FTP, AS2 )

26 Systemarchitektur Integration oder Teilung Mit den Daten entscheiden alle Daten in einem System oder Aufteilung auf verschiedene Systeme Welche Art von Daten werden verarbeitet Vertragsdaten (Verträge, Vertragspartner, Abrechnungsdaten) Bewegungsdaten (Zeitreihen, Prognosedaten, Energiemengen) Datenflüsse betrachten viele Daten sollten zusammen verarbeitet werden, unnötige Datenflüsse vermeiden Anzahl der Transaktionen Relativ unabhängige Systeme können getrennt betrieben werden Abrechnung und Energiedatenmanagement (EDM) getrennt EDM und Zählerfernauslesung oder EDM und Prognose zusammen

27 Datenbereitstellung Bilanzierung Prognose BI / DWH Architektur Zeitreihendaten werden per Zählerfernauslesung bereitgestellt aus dem Markt importiert und in vielen Prozessen verarbeitet Datenbereitstellung GPKE & GeLi Bilanzierung MaBiS & GaBi EDM , , ,561 Zeitreihen Datenbank Prognose Business intelligence (BI / Data warehouse) Aufbau einer zentralen Zeitreihenverwaltung mit Zugriff der verschiedenen Prozesse als EnergieDatenManagementsystem (EDM) bzw. MeterDataManagementsystem (MDM)

28 Schnittstelle Systemarchitektur EDM / MDM Abrechnung (stammdatenführend) externes EDM Tarifkunden SVK SOAP/MDUS/XI/PI Externe Marktteilnehmer (VNB, Lieferant, ÜNB, ) Dienstleister (z. B. Wetterdienst) Web-Portal Benutzer-/Zugriffsverwaltung Workflow-gesteuerte Wechselprozesse robotron*wpm Prognose robotron*e~predict Tarifierung/Lastprofilbildung EAI/SOA/ Stammdaten Kommunikationsautomatisierung (UTLMD, MSCONS, ESS, CSV, etc.) Administration EDM/MDM-Kern Berechnungen Zeitreihen-API Ersatzwertbildung Plausibilitätsprüfungen Zeitreihendatenbank + Zusatzmodule externe Lastganganalyse robotron*e~profiler Business Intelligence Stammdaten- Reporting Bewegungsdaten- Reporting Geräteverwaltung Messwerterfassung (SVK, TK) (LP, VD, ZST, Tarifwerte,..) AMR / ZFA robotron*e~smart robotron*e~collect Zertifikatsverwaltung Gateway-Administration (Parametrierung, Logbuch-Erfassung, Wake-Up-Call, ) robotron*switchingserver / robotron*e~ecollect-kommunikationsserver (AMI-Interface) externe Systeme - HSM - Sub-CA - WFM Zähler / Gateways Head-End-Systeme

29 Basisarchitektur EDM System Deployment-Server Deployment per Java Webstart Deployment-Plattform e~count, e~sales, e~collect Webserver Modulregistrierung Systemkommunikation per JDBC Clients Anwendung im Web-Browser Datenbank-Server (EDM-System) Kommunikationsserver

30 Basisarchitektur EDM System EDM Kern Funktionalität in der Oracle DB Verwaltung von Zeitreihen NICHT relational Bereitstellung einer PL/SQL API zum Zugriff auf Zeitreihen Beachtung von Zeitzonen direkt beim Zugriff automatische Periodenkovertierung API auch per SQL nutzbar geringer Platzbedarf durch komprimierte Ablage Performance CPU Last durch API wird durch hohen Datendurchsatz aufgrund Komprimierung kompensiert

31 Das EDM System in der Datenbank kontinuierliche Entwicklung seit 1999 aktuell in Release Packages 6000 Tabellen 2500 Trigger 2200 Views

32 EDM Benutzeroberfläche eclipse RCP eclipse platform project als Basis mit frameworks und services RCP Rich Client Platform zur Umsetzung der Benutzeroberfläche SWT Standard Widget Toolkit zusammen mit JFace zur Darstellung der Benutzeroberfläche JPA Java persistence API in der Ausprägung EclipseLink JPA als objekt-relationale Abbildungsschicht zum Zugriff auf die Datenbank robotron ist

33

34 Web-Portal robotron*e~smart Kundenportal Anzeige von Zählerständen, Tageswerte, Monatsverbräuche, Lastgänge Berechnung/Anzeige CO2-Verbrauch Prognose: Trendberechnung, Jahresverbrauch Kostenberechnung über Tarifprofile und Preise Definition und Anzeige von Sparzielen HTML5 kompatible Darstellung Mehrsprachenfähigkeit

35 Vorteil zentrale Datenhaltung Optimierung der Prozesse und der Datenhaltung am Beispiel Zählerfernauslesung (ZFA) und Energiedatenmanagement (EDM) eigenständige ZFA eigenständiges EDM Auslesung Übertragung Ergebnisse Datenablage (ZFA) Datenexport (ZFA) Datenimport (EDM) Datenablage EDM- Zeitreihenverwaltung EDM und ZFA als integriertes System verzichtbare Prozessschritte Auslesung Übertragung Ergebnisse Datenablage EDM-Zeitreihenverwaltung

36 Big Data robotron*e~smart robotron*e~smart erfolgreiche Verarbeitung von Zählern in weniger als einem Tag Zählerstandsgänge á 96 Werte On-the-fly Lastgangermittlung pro Zählerstandsgang 24 Mio. Zeitreihen parallele Plausibilisierung aller geschriebenen Zeitreihen > 2,3 Mrd. Werte/Tag in einem System

37 Probleme? Sessionmanagement bei hoher Nutzerzahl Sessionpooling, dann allerdings Vorsicht bei Nutzung von Package-Zuständen Caching auf Applikationsserver beachten Auslieferung nicht perfekt unterstützt eigene Lösungen erforderlich Versionierung aller Bestandteile nicht leicht möglich Datenbank basierte Logik wird von wenigen Client-Frameworks unterstützt

38 Interessiert? Einfach selbst ausprobieren Microsoft SQL Server Express MySQL Oracle XE mit Application Express (APEX) DB2 Express-C database server

39 Björn Heinemann Geschäftsführer/ Leiter Entwicklung Energiewirtschaft Telefon: Fragen?

40