User:Khflottorp/sandbox

An embedded database system is a NOT A database management system (DBMS), but the data structures tightly integrated with the application software that requires access to stored data.

The embedded database is defined by the application coders, and the data stored in the database is available in the address space of the application, one can request a record, and receive a pointer to the data structure. The data structure is usually shared by a number of applications, using shared memory, and methods to access the memory should be contained in a shared library.

Conventional data modelling tools are usually used to define the embedded data repository, but it is made when the first application is started and loaded with data from persistent storage, usually in a conventional database management system (DBMS). The persistent storage is updated with the content in the embedded database, where special code has been written for this. So, when the embedded database is updated, the (e.g. Oracle) database may be updated as well, but it will be done with regular intervals to allow other systems to measure change - "trend".

It is actually a broad technology category that include embedded database systems with differing application programming interfaces but of course, no SQL, all are proprietary, native APIs; no client-server since all are in-process; and very few have storage modes, all are in-memory. The database models have been designed with regular database tools for (relational, object-oriented, entity–attribute–value model and network/CODASYL.

The term embedded database can be confusing because only a small subset of embedded database products is used in real-time embedded systems such as telecommunications switches and consumer electronics devices. See mobile database for small-footprint databases that are used in mobile devices. On your smartphone (Android), iSql is used to hold your contacts and appointments, but this does not make it to an "embedded database". They use an RDBMS to allow synchronisation tools to be made separately from the phone. Embedded refers to sharing the same address space which implies that the application can access data structures directly "embedded" in the other data structures and code. The application can read locked records and erase it all with erroneous code. Your car may have an embedded database. This stores speed, turning, tilt, lights and all the buttons. Here some sensors signals applications that feeds the database; that you turn the lever to turn right, may trigger the driver for the right light to turn the light on for a while, and off, and back on - and then another application makes a clicking sound and light up dashboard to alert you of the blinking. The application need to know how the other applications provide data, where and how to find it, use a common set of methods or "API". That you turn a knob or press a button or touch a lever are events that should trigger your car to respond. The old wires to the relays have been replaced by a sensor that sends to an application that updates an embedded database. "How" the light blinks is irrelevant, how it accelerates when you press the pedal the same. In better cars, the repair shops can access this database and "see" what you did the last miles, every time you braked - how did the pads work, measured oil pressure, and detect when you changed oil and forgot the replace the filter. Full database management is needed first when there is a need for others to access the data. In a large factory, machines are replaced all the time and how to manage and operate this will at some point be complex enough to require a full DBMS to allow user applications to provide additional information and commands that the old system did not support. These machines - "modules" and "packages" are complex and the systems and applications used to operate this is "Embedded systems" that we see as a module, and interface with M2M methods.