Unit - 6
Advances in Databases
A database with a set of triggers is known as an active database. Because of the complexity involved in understanding the effects of various triggers, maintaining these databases is extremely tough. Prior to executing the statement in such a database, the DBMS examines if the specific trigger indicated in the statement that modifies the database is enabled or not.
If the trigger is active, the condition section is executed first, followed by the action part only if the stated condition is true. It is possible to use a single sentence to activate many triggers.
In this case, the DBMS processes each of the triggers at random. The execution of a trigger's action portion may activate other triggers or the same trigger that initiated the action. The term "recursive trigger" refers to a type of trigger that triggers itself. Although the DBMS performs such trigger chains in a pre-defined manner, it has an impact on the concept of comprehension.
Features
● It has all of the features of a traditional database, such as data modeling capabilities and query language, multi-user access, and recovery.
● It has all of the features of a standard database, such as data definition, data manipulation, and storage management.
● Data definition, data manipulation, storage management, transaction management, concurrency control, and crash recovery are all supported, as are all the operations of a typical database.
● ECA-rules are defined and managed using an active database.
● An active database must be able to detect the occurrence of events.
● An active database must be capable of evaluating conditions and carrying out activities.
● An event-driven architecture is part of an active database (often in the form of ECA rules)
● An active database should be programmable and support a programming environment.
Application
- Applications that rely on data monitoring activities, such as CIM, Telecommunications Network Management, Program Trading, Medical, and Financial Decision Support Systems, can benefit considerably from active database integration.
- Controlling production, such as in power plants.
- Routine maintenance, such as inventory control.
- Financial applications, such as trading stocks and bonds.
- Network and telecommunications management.
- Air traffic control.
- Computer Integrated Manufacturing (CIM)
- Tools for compiling statistics and authorizing transactions.
Weakness
● There is a lack of methodological support in the design and analysis.
● Standardization is lacking.
● Triggers are missing development and administration tools.
● Poor performance: One of the primary reasons why users are hesitant to employ active rules in the creation of large applications is because of their poor performance.
● The isolation of transactions and triggers, as well as the misunderstanding of their delicate interconnections, make it difficult to optimize large programs.
● Many active database management system prototypes lack support for application development.
● Active databases have mostly been considered in centralized database setups, hence distribution and parallelism have not been frequently considered.
Deductive database
Not just facts, but also general principles, are stored in a deductive database. These rules can be used to infer new facts that aren't explicitly reflected in the database; data can be stored implicitly using these rules.
Take a look at the deductive database below:
“John is Bill’s father.” “Bill is Derek’s father.”
“IF x is y’s father AND y is z’s father, THEN x is z’s grandfather.”
This database also contains a rule that indicates the grandfather relationship between two entities, in addition to the two facts. By substituting x = "John," y = "Bill," and z = "Derek" into the formula, the database can establish the statement "John is Derek's grandfather."
This type of rule has the effect of defining new relationships that aren't explicitly recorded in the database. Implicit or virtual relationships are what they're called. Base relations are explicit relationships, such as the father relationship described above.
The intensional database (IDB) is a collection of virtual relations, whereas the extensional database is a collection of basic relations (EDB). First-order logic is used in deductive database systems. We can express both facts and rules about facts using the same vocabulary using first-order logic.
A deductive database is a database that has been enhanced with an inference system. Deductive databases arose from a desire to integrate logic programming and relational databases in order to build systems that enable a powerful formalism.
Database + Inference → Deductive database
The immediate benefit is that it may be possible to reduce the amount of storage space required for data.
We often express rules in a deductive database system using a declarative language—a language in which we specify what we want to do rather than how we want to achieve it.
By interpreting these rules, a system's inference engine (or deduction mechanism) can derive new facts from the database.
Although deductive databases are not widely utilized outside of academics, some of its concepts are used in relational databases today to support the advanced features of more contemporary SQL standards.
Specification
● Prolog was utilized as a starting point for logic-based deductive database work. Datalog, a variant of Prolog, is used to declaratively define rules in conjunction with an existing collection of relations, which are handled as literals in the language.
● Facts and rules are the two sorts of specifications used in a deductive database.
● Data saved as relations in a relational database is referred to as facts.
● Facts are expressed similarly to relations, with the exception that attribute names are not required.
● Relational views and rules have a lot in common. They define virtual relationships that aren't actually recorded but can be derived from facts using inference techniques based on rule descriptions.
Main memory database
The Main Memory Database is permanently stored in the system's Main Memory. On the hard drive, there is a backup copy of the database. In contrast to database management systems, which use a disk storage method, it primarily relies on main memory for computer data storage. In Memory Database is another name for it.
The main memory database is a database system that stores computer data largely in main memory. Because disk access is slower than memory access, they are faster than disk-optimized databases. Additionally, the internal optimization is simpler and uses fewer CPU instructions.
Features
● Data can be accessed directly and shared memory architecture is used.
● There is no data duplication or network overhead.
● They are inextricably linked.
● They happen at the same time.
● Transactions that are completely ACID.
Advantages
● It uses shared memory architecture and has immediate access to data.
● It's written by hand with atomic instructions.
● It has allocators with fixed and variable sizes.
● The performance-critical code parts are tightly connected.
Disadvantages
It's possible that they won't be cost-effective.
There is a chance that data will be lost.
The database has a capacity limit.
Applications
Embedded real-time systems use this.
In an MP3 player, manage the music databases.
Data programming in set-top boxes, mathematical trading, and other financial applications are all examples of this.
Sites for e-commerce and social networking.
Semantic database
The semantic data model (SDM) is a database description and organizing formalism (database model) based on semantics. This database model is intended to capture more of the meaning of an application environment than current database models allow. The types of entities that exist in the application environment, their classifications and groups, and the structural relationships among them are all described in an SDM specification. SDM is a set of high-level modeling primitives that can be used to capture the semantics of an application environment.
SDM allows the same information to be seen in several ways by including derived information in a database structure definition; this allows it to directly satisfy the wide range of needs and processing requirements that are common in database applications. The current SDM was created based on our experience with an early version of it. SDM is a database management system that aims to improve the efficiency and usability of database systems.
An SDM database description can be used as a formal database specification and documentation tool, as well as a foundation for supporting a variety of powerful user interface facilities, a conceptual database model in the database design process, and the database model for a new type of database management system.
Semantics is a new branch of information science research and development, however the concept has been around much longer than computers! To begin, semantics is the discipline of linguistics and logic that deals with the concept of meaning. This can be broken down into three major categories:
● Formal Semantics
○ Logical aspects of meaning:
■ Sense
■ Reference
■ Implication
■ Logical form
● Lexical Semantics
○ Word meaning
○ Word relations
● Conceptual Semantics
○ Cognitive structure of meaning
To begin, the phrase "semantic data model" is traditionally used in conjunction with the term "semantic database." When you hear the term "semantic data," it usually conjures up images of the Semantic Web, Web Ontology Language (OWL), and Resource Description Format (RDF).
Semantic web
"The semantic web is a vision of information that can be easily interpreted by machines, allowing machines to do more of the laborious work of discovering, combining, and acting on web data." The Semantic Web is a system that allows machines to "understand" and reply to complicated human queries based on their meaning, as it was originally envisioned.
OWL and RDF
Unfortunately, OWL and RDF have taken over the original concept and language coined by Tim Berners-Lee (also the inventor of the World Wide Web). Subject-predicate-object expressions are the emphasis of OWL and RDF, where "the subject denotes the resource, and the predicate denotes qualities or aspects of the resource and expresses a relationship between the subject and the object."
It all started in the 1960s, when "Richard Montague devised a system for defining semantic entries in the lexicon in terms of the lambda calculus." The syntactic parse of the sentence John ate every bagel would be constituted of a subject (John) and a predicate (eat every bagel); Montague demonstrated that the meaning of the sentence could be dissected into the meanings of its pieces and a few rules of combination."
Key takeaway
- A database with a set of triggers is known as an active database. Because of the complexity involved in understanding the effects of various triggers, maintaining these databases is extremely tough.
- A deductive database is a database that has been enhanced with an inference system. Deductive databases arose from a desire to integrate logic programming and relational databases in order to build systems that enable a powerful formalism.
- The Main Memory Database is permanently stored in the system's Main Memory. On the hard drive, there is a backup copy of the database.
- The semantic data model (SDM) is a database description and organizing formalism (database model) based on semantics. This database model is intended to capture more of the meaning of an application environment than current database models allow.
Semi-structured data comprises tags or other types of mark-up that identify separate, distinct things within the data, but does not comply to the standards of regular structured data.
Nested data structures and the lack of a fixed schema are two major characteristics that separate semi-structured data from structured data:
● Before structured data can be imported and queried in a relational database system, a fixed schema must be specified. Semi-structured data does not require the creation of a schema in advance and can change over time, with new properties being added at any moment.
Furthermore, even though they are grouped together, entities inside the same class may have various properties, and the order of the attributes is irrelevant.
● Semi-structured data, unlike structured data, which is represented as a flat table, can contain n-level hierarchies of nested information.
Data that does not correspond to a data model but has some structure is referred to as semi-structured data. It doesn't have a set or rigid structure. It's information that isn't stored in a logical database but has some organizational characteristics that make it easier to analyze. We can save them in a relational database with the help of various procedures.
Features
● Although data does not follow a data model, it does have some structure.
● Data cannot be kept in rows and columns like it can in databases.
● Tags and elements (metadata) are used to group data and explain how it is kept in semi-structured data.
● Identical entities are grouped and organized in a hierarchy.
● The attributes and properties of entities in the same group may or may not be the same.
● There is insufficient metadata, making data automation and management challenging.
● In a group, the size and type of the same properties may differ.
● It is difficult for computer programs to use due to the lack of a well-defined structure.
Sources of semi structured data
● E-mails
● XML and other markup languages
● Binary executables
● TCP/IP packets
● Zipped files
● Integration of data from different sources
● Web pages
Advantages
● A predefined schema does not confine the data.
● Schema is flexible, in the sense that it can be easily altered.
● Data can be moved around.
● Structured data can be viewed as semi-structured data.
● It assists customers who are unable to explain their requirements in SQL.
● It can handle a wide range of sources with ease.
Key takeaway
- Semi-structured data comprises tags or other types of mark-up that identify separate, distinct things within the data, but does not comply to the standards of regular structured data.
- Data that does not correspond to a data model but has some structure is referred to as semi-structured data.
JSON (JavaScript Object Notation) is a data-exchange format based on a subset of the JavaScript Programming Language.
Any program can generate JSON data. Among the most common instances are:
● Native methods are used by JavaScript applications to generate JSON.
● Non-JavaScript apps generate JSON data using libraries (typically with extensions).
● JavaScript generators that can be used on the fly.
● JSON documents are concatenated (which may or may not be line-separated).
There are major discrepancies between various implementations due to the lack of a written specification. Because of these differences, importing JSON-like data sets is impossible if the JSON parser's language specification is rigorous. Snowflake follows the concept "be liberal in what you accept" to make importing JSON data sets as painless as possible. The goal is to take as many JSON and JSON-like inputs as feasible, allowing for unambiguous interpretation.
Basic JSOn Syntax
JSON data is a collection of name/value pairs organized into objects and arrays in a hierarchical structure:
● Colons: separate names and values in name/value pairs.
● Curly braces {} denote objects.
● Square brackets [] denote arrays.
● Commas, separate entities in objects and arrays.
Syntax and structure
A JSON object is a data format that uses curly brackets to represent key-value pairs. When working with JSON, you'll most likely see JSON objects in.json files, but they can also exist in the context of a program as a JSON object or string.
The following is an example of a JSON object:
{
"first_name": "Sammy",
"last_name": "Shark",
"location": "Ocean",
"online": true,
"followers": 987
}
Although this is a very small example, and JSON can be many lines long, it demonstrates how the format is often set up with two curly braces (or curly brackets) on either end, and key-value pairs filling the space in between. The majority of data in JSON is wrapped in a JSON object.
Key-value pairs have a colon between them as in "key" : "value". Each key-value pair is separated by a comma, so the middle of a JSON looks like this: "key" : "value", "key" : "value", "key": "value". In our example above, the first key-value pair is "first_name" : "Sammy".
On the left side of the colon are JSON keys. They must be included in double quotes, as in "key," and can be any valid string. Keys within each object must be distinct. These key strings can contain whitespaces, such as "first name," but this makes it more difficult to access while programming, therefore use underscores instead, as in "first name."
Name / Value pair
A field name (in double quotes), a colon, and then a value make up a JSON name/value pair.
Example
{"firstName":"John", "empid":45611}
Supported data types
A value in a name/value pair can be:
● A number (integer or floating point)
● A string (in double quotes)
● A Boolean (true or false)
● An array (in square brackets)
● An object (in curly braces)
● Null
XML
The markup language XML (Extensible Markup Language) offers a set of rules for encoding texts. It was based on SGML, another markup language that was created to standardize the structure and elements of a document.
Since its initial concentration on documents, XML has expanded to include a wide range of applications, including the representation of arbitrary data structures and serving as the basic language for communication protocols. It has become one of the most widely used protocols for data interchange on the Web due to its extensibility, versatility, and usability.
The following constructs make up the majority of an XML document:
● Tags (identified by angle brackets, < and >)
● Elements
Elements are normally made up of a “start” tag and a corresponding “end” tag, with the text between the tags forming the element's content. An element can also be made up entirely of "empty-element" tags with no "end" tags. The “start” and “empty-element” tags can have attributes that help describe the element's properties or metadata.
Example
<?xml version="1.0"?>
<!DOCTYPE parts system "parts.dtd">
<?xml-stylesheet type="text/css" href="xmlpartsstyle.css"?>
<parts>
<title>Automobile Parts & Accessories</title>
<part>
<item>Spark Plugs</item>
<partnum>A3-400</partnum>
<price> 27.00</price>
</part>
<part>
<item>Motor Oil</item>
<partnum>B5-200</partnum>
<price> 14.00</price>
</part>
<part>
<item>Motor Oil</item>
<partnum>B5-300</partnum>
<price> 16.75</price>
</part>
<part>
<item>Engine Coolant</item>
<partnum>B6-120</partnum>
<price> 19.00</price>
</part>
<part>
<item>Engine Coolant</item>
<partnum>B6-220</partnum>
<price> 18.25</price>
</part>
</parts>
Key takeaway
- JSON (JavaScript Object Notation) is a data-exchange format based on a subset of the JavaScript Programming Language.
- The markup language XML (Extensible Markup Language) offers a set of rules for encoding texts. It was based on SGML, another markup language that was created to standardize the structure and elements of a document.
An object–relational database (ORD) or object–relational database management system (ORDBMS) is a database management system (DBMS) that is similar to a relational database but uses an object-oriented database model in which objects, classes, and inheritance are supported directly in database schemas and query languages. It also allows for the extension of the data model with custom data types and procedures, exactly as pure relational systems.
An object–relational database is a type of database that sits halfway between relational and object-oriented databases. The methodology in object–relational databases is substantially the same as in relational databases:
At one extreme are OODBMSes, in which the database is essentially a persistent object store for software written in an object-oriented programming language, with a programming API for storing and retrieving objects and little or no specific support for querying; at the other extreme are OODBMSes, in which the database is essentially a persistent object store for software written in an object-oriented programming language, with a programming API for storing and retrieving objects, and little or no specific support for querying
The primary requirement for an object–relational database stems from the reality that both relational and object databases have distinct advantages and disadvantages. The relational database system's isomorphism with a mathematical relation allows it to apply many relevant set theory techniques and theorems.
However, these databases aren't ideal for certain sorts of applications. Containers such as sets and lists, as well as arbitrary user-defined datatypes and nested objects, are all possible in an object-oriented database paradigm. This eliminates the issue of impedance mismatch by bringing application type systems and database type systems closer together. However, unlike relational databases, object databases do not provide a mathematical foundation for extensive analysis.
One of the ORD's objectives is to close the gap between relational and object-oriented database conceptual data modelling techniques such as the entity-relationship diagram (ERD) and object-relational mapping (ORM). It also aims to connect the gap between relational databases and the methods of object-oriented modelling that are commonly used in programming languages such as Java, C# and C++.
Advantages of object relational database
The benefits of the Object Relational model are −
● Inheritance
The Object Relational data model makes it possible for its users to inherit structures, tables, etc. so that their functionality can be expanded. Inherited objects include new attributes as well as the attributes that were inherited.
● Complex data type
Using existing data types, complex data types can be created. This is useful as complex data types allow better data manipulation in the Object Relational Data Model.
● Extensibility
In the Object relational data model, the functionality of the framework can be expanded. Using complex data types, as well as advanced object-oriented model principles such as inheritance, this can be accomplished.
Disadvantages
At times, the object relational data model can become very complex and difficult to manage since it is a mixture of the object-oriented data model and the relationship data model and uses the features of both of them.
Table inheritance
Table inheritance is only supported for tables that are defined on named row types. The property that permits a table to inherit the behavior (constraints, storage options, and triggers) of the supertable above it in the table hierarchy is known as table inheritance. A table hierarchy is a relationship between tables that allows subtables to inherit the behaviors of supertables. The following are some of the benefits of table inheritance:
● It encourages you to implement your data model in modules.
● It ensures that schema components are reused consistently.
● It enables you to create queries with a scope of any or all of the tables in the table hierarchy.
A subtable inherits the following properties from its supertable in a table hierarchy:
● All constraint definitions (primary key, unique, and referential constraints)
● Storage option
● All triggers
● Indexes
● Access method
Object relational mapping
Without having to write SQL queries, an object-relational mapper creates an object-oriented layer between relational databases and object-oriented programming languages. It standardizes interfaces, which reduces boilerplate and speeds up development.
Object-oriented programming has a large number of states and codes in a difficult-to-understand-and-interpret manner. ORMs take this information and turn it into a structured map that developers may use to comprehend the database's structure. The mapping explains the relationships between items and tables.
ORMs employ this information to transform data across tables and generate SQL code for inserting, updating, creating, and deleting data in a relational database in response to changes made by the application to the data object. The ORM mapping will take care of the application's data needs once it's written, and you won't have to write any additional low-level code.
ORM has three techniques to address the object code and relational database mismatch: bottom up, top down, and meet in the middle. Each strategy has its own set of advantages and disadvantages. Developers must fully comprehend the environment and design requirements before selecting the finest software solution.
ORM's advantages include, in addition to the data access technique:
● Because it automates object-to-table and table-to-object conversion, it simplifies development and lowers maintenance expenses.
● In comparison to embedded SQL and handwritten stored procedures, there is less code.
● In the application tier, transparent object caching improves system speed.
● An efficient solution that makes it faster and easier to maintain an application.
The rise of ORM in numerous application development has sparked debate among specialists. The performance of ORM is a major concern, and stored procedures may be a better option. Furthermore, in some cases, ORM dependency might lead to poorly built databases.
Types of ORM
The active record pattern and the data-mapper pattern are the two methodologies used by ORMs.
Active record pattern
This method organizes data within the code's object structure. Within your computer code, you manage data using classes and structures. Because the database structure is intimately linked to the code, it is difficult to remove the database and migrate it to a different application using this method.
Data-mapper patterns
The data-mapper pattern tries to separate the database from the business logic in the objects. This split makes it simpler to switch databases while maintaining the same programming logic.
Advantages
ORM technologies are popular among OOP programmers because they reduce the amount of SQL expertise needed to link a database to a program. ORMs also produce SQL code for you, allowing you to concentrate on creating business logic. Using object-related mappers to manage the interface between applications and databases has four major advantages.
Productivity
Data-access code takes time to write and adds little benefit to the application's functionality. It's essentially the code's plumbing. Using a technology like an ORM that creates data-access code automatically saves a lot of effort that isn't adding value to the application. In some circumstances, the ORM can write the entirety of the application's data-access code. The ORM can also assist you in keeping track of database changes, making future debugging and updates easier.
Application design
Design patterns are used in a well-written ORM to push you to utilize best practices for application design. You don't need to develop a flawless database schema in advance if you use an ORM to manage the data interface. You will be able to simply alter the current interface. You may also switch out data for different applications by separating the database table from the programming code.
Code reuse
Creating a class library to generate a second dynamic-link library is one technique to reuse data (DLL). You don't have to replicate the data-access code when creating a new application.
Reduced testing
You don't have to spend as much time testing the data-access code because the ORM generates well-tested code. You can concentrate on testing the business logic and code instead.
Disadvantages
ORMs are a great tool for a lot of things, but there are a few limitations to utilizing them for data-access apps, according to several developers. The problems appear to be related to the application's complexity. A high level of abstraction aids the development process in basic applications. When the applications are complicated, however, abstraction hides many of the specifics that are required to address data-related difficulties.
Performance
The extra code generated by the ORM is a typical gripe among OOP developers. The extra code slows down the application and makes it more difficult to maintain. A well-designed ORM should be capable of producing high-quality code without slowing down the application.
Need to Know SQL
High-level abstractions don't always result in the optimal SQL code, and developers can't always rely on the ORM. You'll still need to know SQL and the ORM's produced syntax.
Poor Mapping
ORMs can occasionally result in erroneous mappings between data tables and objects. These issues might cause application issues and can be difficult to spot. Even though business applications rarely have many one-to-one relationships, ORMs encourage one-to-one mapping.
Effects on Schema and Migrations
It's generally difficult to improve data structures when the ORM layer is poorly developed. It can often limit your selections, and your options may be limited depending on the ORM. If your ORM doesn't support migrations, writing migrations in OOP is more difficult than writing migration code in SQL. A well-written ORM will offer features to make database migrations easier in the future.
Key takeaway:
- An object-oriented database is structured rather than behaviour, and data rather than logic, around objects.
- An object-oriented database is a set of relational databases and object-oriented programming.
- An object-relational database can also be referred to as a relational object database management system.
- It also aims to connect the gap between relational databases and the methods of object-oriented modelling that are commonly used in programming languages such as Java, C# and C++.
- Without having to write SQL queries, an object-relational mapper creates an object-oriented layer between relational databases and object-oriented programming languages.
- It standardizes interfaces, which reduces boilerplate and speeds up development.
There is a requirement to manage geometric, geographic, or spatial data, which is data about space, in a variety of industries. The space of interest could be a two-dimensional abstraction of (parts of) the earth's surface – the most well-known example being geographic space –, a man-made space like the layout of a VLSI design, a volume containing a model of the human brain, or another 3d-space representing the arrangement of chains of protein molecules, for example. There have been attempts to manage such data in database systems at least since the inception of relational database systems.
The ability to deal with enormous collections of relatively simple geometric objects, such as a set of 100 000 polygons, is a feature of the technology evolving to meet these needs. Although the difficulties are obviously connected, this is slightly distinct from domains like CAD databases (solid modeling, etc.) where geometric entities are organized hierarchically into complicated structures.
Pictorial, picture, geometric, geographic, or spatial database systems have all been used to describe database systems that provide such support. Because the data to be maintained is frequently captured in the form of digital raster images, the names "pictorial" and "image" database systems were coined (e.g. Remote sensing by satellites, or computer tomography in medical applications).
Geographic data
Road maps, land-use maps, topographic elevation maps, political maps with boundaries, land-ownership maps, and so on are examples of geographic data. Geographical information systems (GIS) are specialized databases that store geographic information. In certain instances, geographic data differs from design data. Geographic data includes things like maps and satellite photos. Not only can maps convey location information such as altitudes, but they may also provide other types of information. Soil type, land type, and yearly rainfall are all factors to consider.
Geographic information can be used to determine a range of demographic characteristics. You can compare fundamental details such as economic condition, average age, and ethnic variety in different parts of the country using information collected from studies employing geographic data.
At GeoLytics, our census and demographic solutions allow you to investigate hundreds of factors on a large and small scale. You can compare features of the Texas population to those of Massachusetts, for example, by focusing on geographic borders at the state level. You can get a sense of the area's growth trends and even particular customer purchasing habits.
A geographic information system (GIS) is a system for acquiring, storing, displaying, updating, manipulating, and analyzing spatial data that uses a combination of hardware and software. GIS is also an interdisciplinary field that includes many different topics of study, such as:
1. Geodesy that is basically projection, surveying, cartography and so on.
2. Remote Sensing
3. Photogrammetry
4. Environmental Science
5. City Planning
6. Cognitive Science
As a result, advances in domains like computer science, databases, statistics, and artificial intelligence are crucial to GIS. All of the various difficulties and questions that occur as a result of the integration of multiple disciplines result in a tool that is far more than a simple tool.
As opposed to aspatial data, geographic data has its own set of features. They have a number of characteristics, one of which is that they are scale-dependent. Different spatial resolutions, such as different pixel sizes in remote-sensing photos or different census areal units in population censuses, can be gathered or calculated for. As a result, we can divide space into many scale levels. Even if the geographical scale is kept relatively constant, there are numerous, if not infinite, ways to construct regions, and data can be tabulated using these various partitioning schemes.
To put it another way, area boundaries can be changed at various scale levels or according to multiple zonal patterns at roughly the same scale, and data can be tabulated using these many zonal systems. However, even if the same variables are utilized and the same areas are investigated, it is doubtful that data tabulated according to multiple zonal systems will produce consistent results.
Requirement
Geographic information necessitates a method of integrating data from several sources with varying degrees of accuracy. Because the system deals with facets of daily life, it must be updated on a daily basis to remain current and dependable. Much of the information stored in GIS is practical in nature and requires specialized retrieval and modification techniques.
Rather than simple data, the GIS system and application deal with information that can be considered as data with unique meaning and context.
Geometric data
Because they assume an endless collection of points (or another version of the same continuum assumption), spatial notions are often not directly implementable and must be discretized. In geography, discretization is a typical modeling phase, but it can also be viewed as sampling and averaging for normal raster cells. Another drawback of spatial notions is that some of them are only informally articulated in terms of cognitive processes and experiments, rather than being formalized.
A well-defined set of objects and operations on these objects is required in a geometric data model. This satisfies the "formal definition" criterion. In order for the model to be implemented on a finite computer system, the set of objects (instances) must be finite. The model's behavior is expressed in terms of the consequences of the defined (change) operations that can be observed using the given (observe) operations. These geometric data models can usually be mapped to standard data models as specialized application schemata (excluding a discussion of performance aspects).
A short list of geometric data models and their features as determined in a geographic information system follows as an example.
Regular tessellations of space (raster)
A finite number of small, regular shaped areas that tessellate the continuous space can be used to model it. This is a simple and useful method of discretizing space, which can be accomplished either through regular sampling, which determines the value for a specific location, or by averaging over the entire area.
Point sets using interpolation
We can record the value of an attribute at certain places, either on a grid or randomly dispersed, and then apply an interpolation algorithm to obtain a value for all intermediate points.
There are numerous variations on this theme, depending on the amount of points that can be arranged and the interpolation methods that are assumed.
Spaghetti
Simple lines can be used to express spatial concepts; this model is frequently linked to a cartographic modelization, which portrays reality as a map, and then the data model is used to represent the map (and thus indirectly reality). The lines themselves can be depicted using a series of points connected by straight lines, or more advanced interpolation algorithms can be used.
Graph
The graph concept is easily transformed into a data model. Restrictions, such as planarity of the graph, may be applied to make implementation easier.
Key takeaway:
- There is a requirement to manage geometric, geographic, or spatial data, which is data about space, in a variety of industries.
- Pictorial, picture, geometric, geographic, or spatial database systems have all been used to describe database systems that provide such support.
- As opposed to aspatial data, geographic data has its own set of features. They have a number of characteristics, one of which is that they are scale-dependent.
- A well-defined set of objects and operations on these objects is required in a geometric data model. This satisfies the "formal definition" criterion.
References:
- Silberschatz A., Korth H., Sudarshan S., "Database System Concepts", McGraw Hill Publishers, ISBN 0-07-120413-X, 6th edition
- Kevin Roebuck, “Storing and Managing Big Data - NoSQL, HADOOP and More”, Emereopty Limited, ISBN: 1743045743, 9781743045749
- Joy A. Kreibich, “Using SQLite”, O'REILLY, ISBN: 13:978-93-5110-934-1
- Ivan Bayross, “SQL, PL/SQL the Programming Language of Oracle”, BPB Publications SBN: 9788176569644, 9788176569644
- Seema Acharya, “Demystifying NoSQL”, Wiley Publications, ISBN: 9788126579969
