Jusletter IT

Bei der Ablöse eines Computerprogramms durch ein anderes stellt sich die Frage, was hierbei übernommen werden darf. Dies ist umso relevanter, wenn die „neue“ Version durch einen anderen Anbieter erstellt wird, oder zB kommerzielle Software durch Open-Source+Neuprogrammierung ersetzt werden soll. Klar ist hierbei, dass eine Übernahme des konkreten Programmcodes problematisch ist, da es sich in den meisten Fällen um ein urheberrechtlich geschütztes Werk handeln wird. Ebenso offensichtlich ist, dass das Ersatz-Programm die gleichen Aufgaben erfüllen darf wie das abzulösende Vorbild. Unklar ist jedoch die Frage, wie mit den in vielen Programmen enthaltenen Daten umzugehen ist: Die Daten selbst gehören dem Nutzer des Programms, sodass er diese auch weiterhin nutzen darf, und der Programmhersteller kann dies nicht verhindern. Doch was ist mit der Struktur der Daten, welche durch das ursprüngliche Programm bestimmt wird? Ist dies ein Hindernis bei der weiteren Nutzung der Daten, selbst wenn das auf sie zugreifende Programm komplett und unabhängig neu geschaffen wird?

Als konkretes Beispiel kann eine Web-Software dienen, welche eine Benutzerdatenbank enthält: Diese beinhaltet Daten über die verschiedenen Kunden des Betreibers der Website, uA deren Adresse (zur Lieferung von Waren) sowie eine oder mehrere Klassifikationen dieser Personen, zB nach der Häufigkeit des Einkaufs, des durchschnittlichen Warenwerts, der Bonität, aber auch vergleichsweise triviale wie Land (muss nicht mit der Lieferadresse übereinstimmen) oder welcher/welchen Version(en) der AGBs/Datenschutzbestimmungen/... zu welchen Zeitpunkten zugestimmt wurde. Diese Daten sollen zweifellos auch im neuen Programm Verwendung finden. Dennoch wurden zB die Klassen, welche für die Speicherung in der Datenbank verwendet wurden (zB mittels ORM-Layer) von der ersten Firma erstellt. Was, wenn diese Struktur nun besonders komplex und/oder kreativ ist? Darf dann die „nackte“ Datenbank identisch übernommen werden¹ – zusammen mit einer vollständigen Neuprogrammierung der zugehörigen Klassen, aber zwangsweise mit der „alten“ Struktur der Daten in der Datenbank? Ändert es etwas, wenn statt einer objektorientierten Architektur nun eine vollständig andere Art der Programmierung zum Einsatz kommt? Eine solche bedeutet, dass der Aufbau des Programms, das mit den Daten arbeitet, völlig unterschiedlich ist, die Daten selbst aber immer noch exakt die identische Aufteilung in kleinere Elemente, Festlegung ihrer Bedeutung etc besitzen.

Das Urheberrecht schützt „Werke“, daher stellt sich die Frage: Ist ein Datenmodell² eines? Es muss grundsätzlich „abstrakt“ sein, da es für eine Vielzahl an Datensätzen passen muss, welche ihm entsprechend gespeichert werden. Dennoch ist es konkret genug, eine bestimmte derartige Aufteilung vorzugeben. Insb sind auch für viele Daten unterschiedliche Aufteilungen möglich. So kann zB eine Adresse als ein einziger String gespeichert werden, oder separat als Straße, Postleitzahl und Ort. Doch ist die Postleitzahl eine Zahl oder eine Zeichenkette? Beinhaltet die Straßenadresse die Hausnummer oder soll diese separat gespeichert werden? Sind zusätzliche Elemente möglich oder verpflichtend (Stiege, Stockwerk, Türnummer etc)? Ein Datenmodell befindet sich daher eher in der Mitte des Spektrums zwischen einem konkreten Computerprogramm (Funktion exakt festgelegt) und einem abstrakten Algorithmus (kann auf viele Arten umgesetzt werden).

Dafür, dass ein Datenmodell eher einer abstrakten Idee ähnelt spricht, dass es durch eine Vielzahl an Programmen näher ausgeführt werden kann. Ein Datenmodell ist ein Konzept einer Aufteilung: Wie diese erfolgt ist jedoch auf viele Arten lösbar. Dies ähnelt stärker einem Algorithmus, der ebenfalls in diversen Programmiersprachen und auf unterschiedliche Art und Weise umgesetzt werden kann³. Compilierungen etc von Programmen zählen hier nicht als Konkretisierung, da es sich um vollautomatische Umwandlungen handelt und nicht um (uU kreative) Handlungen durch Menschen. Auch die Umsetzung eines Datenmodells in einer Programmiersprache muss noch die exakten Datentypen festlegen, ihre Reihenfolge, wie darauf zugegriffen wird, Konsistenzprüfungen etc, wobei auch innerhalb einer Programmiersprache relevante Wahlmöglichkeiten bestehen. Umgekehrt kann ein Datenmodell – noch ohne es umsetzendes Computerprogramm⁴ – nicht automatisiert verwendet (zB „Compiliert“) werden, bzw ist eine automatische Übersetzung in ein Computerprogramm (oder eine Datenbank-Struktur; siehe unten) erst möglich, wenn alle diese Entscheidungen bereits für das geplante Zielsystem getroffen und in maschinenlesbarer Form festgelegt wurden. Für das Beispiel der Software-Ablöse ist dies jedoch nur eingeschränkt hilfreich: Liegen viele Daten in einer konkreten Datenbank vor, so sind diese Auswahlentscheidungen bei der Umsetzung bereits getroffen worden: Die Datentypen stehen fest und können nur sehr eingeschränkt verändert werden.

Aus welchen Elementen besteht ein Datenmodell und wie sind diese auf der Skala Abstrakte Idee – Konkrete Schöpfung einzuordnen?

• Aufteilung der Daten in kleinere Elemente (zB „Adresse“ vs „Strassenname“+„Hausnummer“+„PLZ“+„Ortsname“): Hierbei handelt es sich um ein Konzept, das auf verschiedenste Arten beschrieben und umgesetzt werden kann. Weiters beruht es meistens auf den konkreten Anforderungen des Kunden und steht dem „Urheber“ deshalb nicht frei.
• Datentyp der einzelnen Elemente („Hausnummer“ ist eine Zahl oder eine Zeichenkette → „16a“?): Dies ist schwierig zu beurteilen: Der „allgemeine“ Datentyp (zB Zahl oder Text) ist klar ein Konzept bzw durch die Daten vorgegeben, doch die konkrete Festlegung (zB „Zahl mit 32 Bit Länge ohne Vorzeichen“) ist als Ausdruck zu qualifizieren – die jedoch erst in der Umsetzung des Modells in eine Datenstruktur erfolgt. Hier ist weiters relevant, dass sich die konkrete Festlegung uU je nach Programmiersprache/Datenbank/... zwingend (es steht nur ein Datentyp hierfür zur Verfügung) oder offensichtlich ist. Eine relevante kreative Auswahlmöglichkeit wird hier nur in Ausnahmefällen vorliegen.
• Zusammenhang der einzelnen Element bzw deren Hierarchie („Straße“ besteht aus „Strassenname“+„Hausnummer“, „Ort“ aus „PLZ“+„Ortsname“ und „Adresse“ aus „Straße“+„Ort“): Hier handelt es sich klar um ein gedankliches Konzept unabhängig von den eigentlichen Daten, also ein Ordnungsprinzip,
• wenn auch für einen konkreten Anwendungsfall. Dies basiert zB auf den Anforderungen des Programms oder der natürlichen Struktur der Daten in der Realität und ist keine kreative Lösung.
• Wiederholungsmöglichkeiten (wie viele Adressen kann eine Person besitzen? Sind diese äquivalent oder zusätzlich „markiert“, zB als ein „Hauptwohnsitz“ und eine Vielzahl gleichwertiger „Nebenwohnsitze“ oder ist eine strikte Reihenfolge der Wohnsitze – zB für Zustellungen – erforderlich?): Auch dies basiert auf den Anforderungen oder der natürlichen Struktur und ist daher keine kreative Konkretisierung.
• Codierung der Daten (wird für einen Hauptwohnsitz „HWS“, „1“... als Markierung gespeichert): Welche Werte einen bestimmten Sachverhalt repräsentieren kann sich aus den gespeicherten Daten ergeben, ist jedoch iA sehr frei festlegbar. Hier ist kreative Gestaltung und individueller Ausdruck daher problemlos möglich. Fraglich ist, ob dies noch Teil des Datenmodells ist oder erst bei der Umsetzung in eine Datenstruktur erfolgt. Im Beispiel der SW-Ablöse ist dies jedenfalls festgelegt und soll meist übernommen werden (wobei hier eine Änderung vergleichsweise trivial ist).
• Optionalität: Ist das Datenelement erforderlich oder darf es fehlen? Welche Bedeutung stellt ein fehlendes Datum dar (Leere Hausnummer = „Unbekannt“ oder „Es gibt keine Nummern“?): Hierbei handelt es sich klar um Konzepte. Die Bedeutung eines fehlenden Datums darf nicht mit der Codierung (voriger Punkt) verwechselt werden: Die Codierung bestimmt, welche Bitmuster gespeichert werden, um eine bestimmte Bedeutung darzustellen. Hier geht es darum, diese Bedeutung festzulegen, was eindeutig zum Modell und nicht zur Struktur gehört. Es ist daher eine freie (und potentiell kreative) Entscheidung festzulegen, wie ein „fehlender“ Wert gespeichert wird, die Bedeutung bzw Zulässigkeit eines solchen ist jedoch strikt davon zu trennen.

Datenmodelle könnten als Computerprogramm geschützt sein. Allerdings könnten sie auch eher als Algorithmus einzustufen sein, der gerade nicht geschützt wird. Ein Ansatz für die Abgrenzung könnte sein, ob es sich um eine ausführbare Festlegung handelt: Ein Algorithmus kann (ohne einen Menschen, dh automatisch) nicht ausgeführt werden, ein Computerprogramm hingegen schon. Dies ist jedoch wenig hilfreich, da Algorithmen natürlich auch festgelegt werden, zB in Lehrbüchern, und der Papierausdruck eines Programms keineswegs ausgeführt werden kann. Als Hinweis kann uU die Definition für Programme in § 1 lit i der WIPO Mustervorschriften für den Schutz von Computersoftware aus dem Jahr 1978 dienen: „Computerprogramm“ ist eine Folge von Befehlen, die nach Aufnahme in einen maschinenlesbaren Träger fähig sind zu bewirken, dass eine Maschine mit informationsverarbeitenden Fähigkeiten eine bestimmte Funktion oder Aufgabe oder ein bestimmtes Ergebnis anzeigt, ausführt oder erzielt. Da ein Datenmodell keine Befehle enthält, kann es sich bei ihm nicht um ein Computerprogramm handeln: die Struktur ist ein rein passives Element; eine Aufbereitung von Daten damit Befehle – welcher Art auch immer – anschließend damit arbeiten können. Daraus ist zu schießen, dass Datenmodelle zwar von Computerprogrammen verwendet werden, aber selbst keine sind.⁵

Hiervon unabhängig ist die Umsetzung des Modells in einem Computerprogramm (Datenstruktur), denn deren Programmstruktur kann sich selbst bei identischen Datenmodellen stark unterscheiden: Handelt es sich um eine prozedurale Umsetzung oder um eine Objektorientierte? Ist es eine flache oder eine tiefe Hierarchie? Was wird als Datenelement modelliert und was als eigene Klasse? Selbst bei absolut identischer Speicherung der Daten, dh identischer Umsetzung des Datenmodells, ist daher eine unterschiedliche Implementierung im Computerprogramm problemlos und auf vielfältige und stark unterschiedliche Arten möglich. Dies spricht ebenso dafür, das Datenmodell separat von der es implementierenden Datenstruktur bzw Computerprogramm zu betrachten. Daraus folgt aber wiederum, dass das Datenmodell eher einem Konzept/Algorithmus ähnelt, und damit nicht geschützt ist.

Ein Datenmodell bzw eine Datenstruktur kann auch mit einer Programmierschnittstelle verglichen werden, einem API: Beide bieten ein Muster für ein Problem. Der Unterschied besteht darin, dass Datenmodell/-struktur sich auf passive Daten bezieht, während ein API dynamische Vorgänge abstrahiert: Elemente davon werden in unterschiedlicher Reihenfolge/Auswahl aufgerufen, je nach Bedarf des Nutzers. Für APIs ist festgelegt, dass diese eingeschränkt bzw in Bereichen urheberrechtlich geschützt sein können.⁶ Dies bedeutet, eine konkrete Schnittstelle kann als Teil eines Computerprogramms geschützt sein, dieser zugrunde liegende Ideen und Grundsätze hingegen nicht; lediglich deren Ausdrucksform. Wird dies analog auf Datenmodelle übertragen, so bedeutete dies, dass die dem Datenmodell zugrunde liegenden Ideen und Grundsätze frei sind, die konkrete Spezifikation jedoch ein „Ausdruck“ derselben wäre. Letzteres könnte auch mit der Datenstruktur gleichgesetzt werden, doch ist diese noch detaillierter. Die „Organisationsidee“ der Daten dürfte daher übernommen werden, ihre „konkrete Umsetzung“ (also noch vor einer Implementierung in einer formalen Sprache!) hingegen bereits nicht mehr. API gelten auch als „Teil“ des Computerprogramms, doch handelt es sich im Gegensatz zu Datenmodellen um konkreten Programmcode – was für Datenstrukturen ebenso gilt. Es wäre daher zu unterscheiden zwischen dem abstrakten Datenmodell an sich, das als „Idee“ ungeschützt wäre, einer konkreteren Festlegung, das bereits Schutz beanspruchen könnte, sowie der Repräsentation der Struktur in einem Computerprogramm – dies führt jedoch zu noch schwierigeren Abgrenzungsfragen. Denn analog zu APIs stellt sich dann die Frage, was genau noch die zugrunde liegende Idee ist, und was schon als konkrete Umsetzung zählt, da letzteres unabhängig von der Programmiersprache sein muss: APIs werden (uA genau deswegen geschaffen!) in einer Programmiersprache bereitgestellt und von einer anderen Programmiersprache aus aufgerufen, sind also Sprachunabhängig. Es kann daher nicht auf die exakte verwendeten Buchstaben ankommen, sondern der geschützte Teil muss sich weiter „hinauf“ erstrecken. Ein Datenstruktur ist daher kein „abstraktes Modell“ mehr, sondern bereits eine konkrete Umsetzung.

Ein Datenmodell kann auch als Dateiformat angesehen werden. Ein Dateiformat legt fest, in welcher Reihenfolge welche Daten gespeichert werden und wie diese repräsentiert werden (Datentyp, spezifische Werte, Abbildung auf Bitmuster). Allerdings ist ein Dateiformat noch „konkreter“, da es sehr genau (mit exakt bestimmten Variationsmöglichkeiten) vorgibt, wie dies zu erfolgen hat und entspricht daher eher einer Datenstruktur. Umgekehrt sind Dateiformate zweifellos Datenstrukturen ebenso wie Datenmodelle. Hier wird auch offensichtlich, dass es sich rein um die Strukturierung der Daten handelt, denn Dateien beinhalten keinen Programmcode (außer als gespeicherten Dateninhalt, der aber hier irrelevant ist).

Für Dateiformate ist die Entscheidung SAS⁷ relevant⁸: Dateiformate sind wie Programmiersprachen zu beurteilen und keine Ausdrucksform des Programms (SAS RZ 39). Problematisch kann jedoch sein, wie das Wissen um das Datei-/Datenformat erlangt wird (SAS RZ 43–44): Decompilierung, unlizenzierter Zugriff auf den Quellcode oÄ sind potentiell Urheberrechtsverletzungen. Wird jedoch nur das Dateiformat selbst (zB durch Analyse von verschiedenen Dateien mit bekanntem Inhalt, oder bei Datenbanken durch Extraktion des Schemas aus diesen) untersucht, so liegt keine Verletzung des Urheberrechts am Computerprogramm vor. Explizit als möglich angesehen wird jedoch ein Schutz durch RL 2001/29⁹, insb das durch diese RL in erweitertem Umfang geschützt allgemeine bzw sonstige Urheberrecht¹⁰ (bzw technische Schutzmaßnahmen; die „neuen“ Elemente dieser RL setzten einen Schutz bereits voraus). Enthält das Dateiformat daher eine Art von „Kopierschutz“ oder ist als eine andere Art von Werk geschützt, könnte dies uU einen Schutz bewirken. Effektiv ist daher auch für Dateiformate als Ausdruck von Datenmodellen festzustellen: Ein Schutz als Computerprogramm scheidet aus.

Es existiert eine Art von Werken, die sehr gut zu Datenmodellen passt, und für die ein Urheberrechtsschutz explizit vorgesehen ist: Datenbankwerke. Diese sind geschützt, wenn Auswahl oder Anordnung der Daten eine eigentümliche Schöpfung ist. Die Auswahl bezieht sich darauf, welche Datenelemente aufgenommen werden, ist also im Hinblick auf Datenmodelle irrelevant. Die „Anordnung“¹¹ betrifft jedoch gerade wie die Daten aufbereitet werden: Welche Eigenschaften sollen in die Datenbank, wie werden sie aufgeteilt etc. Hierfür gelten keine zusätzlichen Voraussetzungen wie zB Aufwand, besondere Kreativität, Einmaligkeit etc: das normale Niveau wie für alle anderen Arten von urheberrechtlich geschützten Werken ist ausreichend¹².

Ein Nebenaspekt ist, dass zwar Datenbanken geschützt sind, diese aber als „Sammlung unabhängiger Elemente“ definiert werden. Dies gilt für das Datenmodell gerade nicht: es enthält (noch) keine Daten und seine Elemente hängen stark voneinander ab¹³. Voraussetzung für einen Schutz ist daher, dass zu einem Datenmodell auch eine es umsetzende Datenstruktur sowie tatsächlich eine Datenbank mit darin enthaltenen Daten existiert, dh es konkret umgesetzt und befüllt wurde. Da, im Gegensatz zu Computerprogrammen, Entwurfsmaterialien nicht zur Datenbank gehören, ist die bloße Beschreibung eines Datenmodells – sei sie auch noch so genau – nicht urheberrechtlich geschützt (die Beschreibung könnte ein Werk der Literatur sein, doch deren Schutz erstreckt sich nicht auf den Inhalt, also das Modell). Für das Beispiel der Software-Ablöse spielt dies keine Rolle (ex existieren zu übernehmende Daten), doch allgemein kann dies relevant sein.

Gerade im Bereich der Informatik ist zu beachten, dass Kreativität eine persönliche menschliche Eigenschaft ist: Was durch externe Vorgaben (zB den Auftraggeber), technische Zwänge, Logik, Zweckmäßigkeit oder übliche Modelle vorgegeben ist, kann hierfür keinen Beitrag leisten¹⁴. Nicht jede „Datenbank“ ist auch eine „geschützte Datenbank“.¹⁵ Bei vielen wirtschaftlich bedeutsamen Datenbanken muss ein weiterer Aspekt Beachtung finden: die enthaltenen Elemente besitzen ohne die Datenbank oft keinen selbständigen Wert. Der Wert der Daten ergibt sich bei ihnen daraus, dass sie in der Datenbank enthalten sind und eine bestimmte Form besitzen. Ein konkretes Beispiel hierfür sind Benutzerberechtigungen: Eine Berechtigung alleine („Personen der Gruppe A dürfen auf Objekt B die Aktion C ausführen“) besitzt zwar auch alleine eine Bedeutung, aber keinen Wert¹⁶. Erst dadurch, dass sie in einem Softwaresystem in der Datenbank enthalten ist und darin Zugriffe regelt, entsteht ihr Nutzen. Wird die Datenbank anders strukturiert, ist eine Übernahme durch Konvertierung kaum bis gar nicht möglich: Die Daten müssten komplett neu erstellt werden. Im konkreten Beispiel müsste auch neu festgestellt (bzw uU sogar festgelegt!) werden, wer was darf (bei Umwandlung zu einem anderen Berechtigungsmodell müssten zB alle Objekte klassifiziert werden anstatt der Personen, Personen müssten neu „eingeteilt“ werden...). Es verschmilzt also die Idee hinter der Datensammlung mit der konkreten Ausprägung des Datenmodells: Ohne dieses ist eine Nutzung kaum bis gar nicht möglich. Dies bedeutet, dass zB bei einer bloßen „Lizenz“ für dieses Datenmodell, wenn es ausreichend kreativ ist, deren Verlust den Verlust der Daten bedeutet.

Daraus ergibt sich gleichzeitig eine Umkehrung: Können die Daten ohne großen Aufwand umstrukturiert und weiter genutzt werden, so liegt eine konkrete (und evtl kreative) Schöpfung vor, welche sich von der abstrakten Idee hinter der Struktur unterscheidet (Beispiel: Umbenennung der Elemente, andere Repräsentation). Ist hingegen eine andere Struktur nicht möglich oder würde zu einem Verlust aller Daten führen (dh diese müssten neu erzeugt werden), so handelt es sich eine abstrakte Idee: Denn existieren keine alternativen Möglichkeiten der Darstellung, so kann auch keine Kreativität in der konkreten Umsetzung liegen: Die Kreativität muss in dem umgesetzten Konzept stecken – und dieses ist urheberrechtlich nicht geschützt.

Ein potentielles Problem dieses Ansatzes könnte darin liegen, dass hier die „kommerzielle Weiter-Nutzung der Daten“ mit den „alternativen Möglichkeiten der Strukturierung der Daten“ verbunden wird. Wenn die wirtschaftliche Bedeutung der Anwendung die mögliche Kreativität einschränkt, so gilt dies naturgemäß auch für alle Alternativen – was vorher nicht möglich war kann auch nachher nicht erfolgen. Dennoch könnten zB zu Beginn der Modellierung zwei große Alternative offenstehen, welche zu deutlich unterschiedlichen Strukturen führen. Erfolgte erst einmal eine Entscheidung für eine davon, können die darin erstellten Daten nicht mehr für die andere Variante genützt werden. Dies bedeutet aber gleichzeitig, dass die Entscheidung schon auf einer sehr hohen Ebene erfolgte, dh zwischen zwei Konzepten und nicht erst bei deren konkreten Modellierung. Als Beispiel: Es existieren verschiedene Arten von Berechtigungssystemen, zB Rollenbasierte, Regelbasierte, Benutzerbestimmbare, Attribut-basierte etc. Hierbei handelt es sich um allgemeine Konzepte. Eine Entscheidung für eines davon liegt daher noch oberhalb einer konkreten Schöpfung. Erst die konkrete Umsetzung des für die Implementierung ausgewählten Modells kann eine solche darstellen. Gleichzeitig ist eine Übernahme der Daten zwischen verschiedenen Konzepten nicht möglich. Innerhalb eines Modells dürfte eine solche jedoch in vielen Fällen zumindest mit nicht allzu hohem Aufwand möglich sein.

Ein weiterer Aspekt bei Datenbanken in der Softwareentwicklung ist, dass in manchen Fällen der verwendete Algorithmus das Datenmodell bzw uU sogar die Datenstruktur bestimmt¹⁷. Auch in solchen Fällen besteht daher keine Wahlmöglichkeit mehr, bzw die mögliche Kreativität ist stark eingeschränkt. Ebenso wenig kann die Anwendung einer bestimmten Systematik oder Methodik beim Entwurf des Modells einen Schutz begründen, da diese eben gerade bei allen Personen gleiche Ergebnisse erzeugen. Und selbst wenn unterschiedliche Ergebnisse möglich sind, müssen diese erst auf einer kreativen Entscheidung des Umsetzers beruhen, und nicht zB auf Effizienzüberlegungen, offensichtlichen Antworten auf Rahmenbedingungen etc.

Konkrete „Hindernisse“ für einen Schutz stellen daher folgende Aspekte dar:

• Der eingesetzte Algorithmus bestimmt/erfordert diese Struktur oder legt sie nahe. Beispiel: Eine Liste/Array beinhaltet lediglich die Daten, ein assoziatives Array oder Hashtabelle benötigt jedoch für jedes Element einen „Schlüssel“ – eine größere Datenmenge und ein zusätzliches Feld (mit besonderen Eigenschaften, insb bei großen Datenmengen) bringt jedoch leichteren (und meist schnelleren) Zugriff auf bestimmte Elemente. Sollen mehrere derartige Zugriffsmöglichkeiten existieren, sind weitere Indizes erforderlich. Für seltene Operationen oder wenn ohnehin alle Elemente bearbeitet werden müssen sind jedoch Arrays besser geeignet.
• Effizienzgründe verlangen diese Modellierung: Muss oft/schnell nach einem bestimmten Element gesucht werden können, ist dieses als separates Element zu modellieren um darauf einen Index aufbauen zu können, ansonsten kann es mit anderen Elementen fusioniert gespeichert werden. Je nach Anwendung ist uU auf besonders geringe Datenmenge zu achten, zB bei der Codierung.
• Das Konzept bzw das Ziel der Datenbank legen die Struktur fest. Beispiel: Eine Adress-Datenbank für mehrere Staaten benötigt ein separates Feld für die Postleitzahl, da sich deren Format, die Position beim Ausdruck etc je nach Land unterscheiden.
• „Programmier-“ bzw „Definitions-“ Sprache: Eine Datenbank wird heute in Software umgesetzt werden müssen, wobei die zu verwendende Sprache (die Syntax, mit der die Struktur beschrieben wird, zB SQL, XML) durch externe/andere Gründe vorgegeben ist. Beispiel: SQL kennt (je nach Produkt) nur wenige Datentypen. Elemente müssen daher auf diese abgebildet werden, wobei nicht bei allen Datentypen alle Funktionen möglich sind. Dies muss bereits im Modell auf hoher Ebene berücksichtigt werden. Beispiel: Joins sind meist nicht auf BLOBs anwendbar, weshalb zB zusätzlich deren Hashwert separat gespeichert wird. XML erlaubt zB eine hierarchische Struktur, was bei SQL-Tabellen nicht möglich ist und auf andere Art darzustellen ist. Gleiches gilt zumindest teilweise für die (Programmier-)Sprache, mit welcher auf die das Modell umsetzende Datenstruktur zugegriffen wird.
• Der Dateninhalt bestimmt die Struktur: Bestimmte Inhalte besitzen eine natürliche Struktur; deren Übernahme liegt daher nahe bzw ist erforderlich. Beispiel: Mitarbeiter eines Unternehmens sind durch eine Identität gekennzeichnet (in vielen Staaten durch eine Versicherungsnummer), ebenso wie durch ihre Position im Unternehmen und ihr Gehalt. Alle diese Elemente sind daher erforderlich, müssen separat gespeichert werden, besitzen einen bestimmten Datentyp usw. Die Modellierung erfolgt fast immer anhand der Realität – diese ist so weit als möglich bzw erforderlich abzubilden und nicht eine neue, beliebig nach Wunsch des Modellierenden andere, zu schaffen.
• Allgemeine Üblichkeit¹⁸: Dies verhindert zwar kein Einbringen von Kreativität, ist aber nicht als solche zu bewerten. Denn was fast jeder in gleicher Weise so lösen würde, ist eben keine individuelle Schöpfung. Gerade im IT-Bereich stellt dies ein praktisches Problem dar – umso ungewöhnlicher ein Problem gelöst wird, umso eher besteht ein Schutz, während die „Standardlösung“ keinen urheberrechtlichen Schutz beanspruchen kann.
• Standard-Vorgehensweisen: Bei relationalen Datenbanken erfolgt zB fast immer eine „Normalisierung“ nach allgemein verbreiteten Grundsätzen. Dies bedeutet, dass sich die Struktur bzw die Aufteilung in kleinere Elemente (hier Tabellen) aus den zu speichernden Daten und diesen Vorgehensweisen automatisch ergibt. Es bleibt daher kaum bis gar kein Spielraum mehr offen. In gleicher Weise ist der Verzicht oder eine Einschränkung der Normalisierung eine wichtige Entscheidung, die sehr früh – und damit auf hoher Ebene – getroffen wird.
• Ziel-Abwägungen: Manche Ziele bei der Entwicklung einer Datenbank widersprechen sich, so zB Speicherminimierung und Geschwindigkeit. Hier besteht daher ein relevanter Spielraum für Entscheidungen der umsetzenden Person. Dennoch ist immer stark zu hinterfragen, inwieweit konkrete Originalität ins Spiel kommt. Dass eine Person reduzierten Speicherbedarf vorzieht, während eine andere mehr auf schnelle Antworten wert legt ist kaum ein Ausdruck der eigenen Persönlichkeit, insb da dies stark bis ausschließlich auf externen Vorgaben beruht¹⁹. Erst wenn die Auswahl Großteils willkürlich ist, dh der Auftraggeber beide Versionen für zumindest annähernd gleich gut die Anforderungen erfüllend hält, kann eine konkrete Auswahl Kreativität begründen²⁰.
• „Entdeckung“: Die Modellierung von Daten eines Unternehmens wird auch als „Entdeckung“ – im Gegensatz zu „Schöpfung“ beschrieben. Der Gedanke hier ist, dass die Datenstruktur vielleicht nicht bekannt ist oder eine falsche Vorstellung davon besteht, bei einer Umsetzung aber nur die „richtige“ Struktur herauszufinden ist, jedoch eine freie Erzeugung gar nicht möglich ist. Mit anderen Worten: Das Datenmodell kann durchaus fehlerhaft sein und andere (besser ausgebildete oder erfahrenere) Personen zu anderen Ergebnissen kommen, aber es ist die beste Beschreibung der Realität, die dieser Entwickler produzieren konnte²¹. Umgekehrt wird die Kreativität bei der Erstellung eines Datenmodells oft beschrieben als „wie das Unternehmen sein sollte, um besser zu werden“. Dies ist jedoch als kreative Idee für ein Unternehmen anzusehen, aus welchem sich dann wiederum auf unkreative Weise ein bestimmtes neues Datenmodell ergibt. Diesfalls wird daher zwar Kreativität eingebracht, aber nicht auf der Ebene des Datenmodells, sondern den Anforderungen, welche ein zu entwickelndes Modell erfüllen soll.

Ein etwas anderer Blick ist, welche Qualitätsanforderungen ein Datenmodell erfüllen soll²²: Vollständigkeit (alle erforderlichen Daten müssen enthalten sein), Nicht-Redundanz (keine Daten sollten mehrfach enthalten sein), Daten-Wiederverwendbarkeit (enthaltene Daten sollten auch für andere noch nicht bekannte Zwecke eingesetzt werden können), Regelerzwingung (was in der Realität unmöglich ist bzw vorhanden sein muss, soll auch im Datenmodell unmöglich bzw erforderlich sein), Flexibilität (bei Änderungen der Anforderungen sollen nur Anpassungen erforderlich sein, aber kein kompletter Neuentwurf), Eleganz (Einfachheit und Klarheit der Darstellung), Kommunikation (das Datenmodell dient auch dazu, anderen Leuten die Struktur mitzuteilen; diese sollte daher leicht verständlich sein), Integration (die Verbindung zu vorhandenen und zukünftigen Datenbanken wie auch Programmen sollte einfach sein), Zielerreichung (sich widersprechende Ziele sollten soweit wie möglich und mit der besten Balance zwischen ihnen erfüllt werden). Elemente bei denen evtl Kreativität einfließen kann sind hierbei lediglich Flexibilität, Eleganz und Kommunikation, wobei auch hier vielfache Einschränkungen (siehe oben) bestehen.

Es ist daher festzustellen, dass bei vielen Datenbanken sehr oft der Freiraum für Kreativität gering bis verschwindend ist, und daher Datenbanken aufgrund der Struktur eher selten urheberrechtlichen Schutz genießen. Sehr viel relevanter ist die Auswahl der Datensätze, bei denen Kreativität viel größeren Raum besitzt. Ebenso wichtig ist der sui-generis Schutz für Datenbanken: Dieser benötigt gerade keine Kreativität, sondern basiert auf der Investition. Und wenn ein Datenmodell durch viele externe und technische Faktoren determiniert und daher nicht kreativ ist, kann es dennoch völlig problemlos sehr schwierig und aufwändig zu erstellen sein²³. Dieser Aufwand kann dann bei der Untersuchung der Schutzfähigkeit in der Kategorie „Darstellung“²⁴ berücksichtigt werden.

Ein bloßes Datenmodell kann keinen urheberrechtlichen Schutz als Computerprogramm erlangen, im Gegensatz zu dem es umsetzenden Programmcode. Demgegenüber ist ein Schutz als (Teil einer) Datenbank möglich, allerdings nur im Zusammenhang mit einer tatsächlichen Umsetzung, dh mit Daten. Denn ohne Daten handelt es sich nicht um eine Datenbank, sodass das bloße Konzept (noch ohne Umsetzung) bestenfalls als Werk der Literatur geschützt ist: dies betrifft dann jedoch die Beschreibung des Datenmodells und nicht das Modell als solches. Ein Schutz ist zwar möglich, wird aber in vielen Fällen nicht tatsächlich vorliegen, insbesondere bei geschäftlichen oder IT-internen Datenbanken. Bei diesen sind die möglichen Freiheitsgrade von vornherein gering und bei den vorhandenen ist es schwer, eigene Kreativität einzubringen. Dies bedeutet weiters, dass bei geschützten Datenbanken uU nicht viel „entfernt“ werden muss, um zu einem ungeschützten Kern zu gelangen: Was technisch determiniert ist, darf (zB nach Entfernung einer kreativen Codierung) kopiert und übernommen werden, zumindest aus urheberrechtlicher Sicht. Ein hier nicht untersuchtes Problem besteht in der Praxis im Wettbewerbsschutz, da die Erstellung eines Datenmodells – wenn auch nicht kreativ – doch mit erheblichem Aufwand verbunden sein kann, dessen „Übernahme“ nicht unbedingt erlaubt sein muss.