Database of Scriptum

Health care nowadays collects data in gigabytes per hour volume. Data mining can help with data reduction, exploration, and hypothesis formulation to find new patterns and information in health care data that surpass human information processing limitations. There is a spread of reports and articles that apply data mining to a wide variety of health care problems and clinical domains and includes diverse projects related to cardiology, cancer, diabetes, finding medication errors, and many others.

Methods in data mining use powerful computer software tools and large clinical databases, sometimes in the form of data repositories and data warehouses, to detect patterns in data. Within data mining methodologies, one may select from an extensive array of techniques that include classification, clustering, and association rules.

Classification

Classification in data mining maps data into predefined groups or classes. Also it is often referred to as supervised learning because the groups or classes are determined before examining the data. Classification algorithms require that the groups or classes be defined based on data attribute values. They often describe these classes by looking at the characteristics of data already known to belong to the classes. Pattern recognition is a type of classification where an input pattern is classified into one of several classes based on its similarity to these predefined classes. One of the applications of classification in health care is the automatic categorization of medical images.

Clustering
Clustering is similar to classification except that the groups are not predefined, but rather defined by the data alone. Clustering is alternatively referred to as unsupervised learning or segmentation. It can be thought of as partitioning or segmenting the data into groups that might or might not be disjointed. The clustering is usually accomplished by determining the similarity among the data on predefined attributes. The most similar data are grouped into clusters.

Clustering can be used in designing a triage system. Triage helps to classify patients at emergency units to make the most effective use of resources distributed. The more important is that accuracy in carrying out triage matters greatly in terms of medical quality, patient satisfaction and life security.

Association rules

Determining association rules is refers to the data mining task of uncovering relationships among data. An association rule is a model that identifies specific types of data associations. These associations are often used in the retail sales community to identify items that are frequently purchased together.

The discovery of new knowledge by mining medical databases is crucial in order to make an effective use of stored data, enhancing patient management tasks. One of the main objectives of data mining methods is to provide a clear and understandable description of patterns held in data. One of the best studied models for pattern discovery in the field of data mining is that of association rules. The accuracy and importance of association rules are usually estimated by means of two probability measures called confidence and support respectively. Discovery of association rules is one of the main techniques that can be used both by physicians and managers to obtain knowledge from large medical databases.

MySQL Workbench provides a graphical tool for working with MySQL Servers and databases. It fully supports MySQL Server versions 5.1 and above. It is also compatible with MySQL Server 5.0, but not every feature of 5.0 may be supported. It does not support MySQL Server versions 4.x.

MySQL Workbench is available in two editions, the Community Edition and the Standard Edition. The Community Edition is available free of charge. The Standard Edition provides additional Enterprise features, such as database documentation generation, at low cost. 

The Community Edition (OSS)

The Community Edition is the foundation of all MySQL Workbench editions—versions that are currently available or those that will become available in the future. All editions of MySQL Workbench are based on the Community Edition and all future improvements to the base framework and feature set will be included in this version. The Community Edition is a full feature product that puts a powerful database management tool into the hands of the MySQL community.

The Standard Edition

The Standard Edition is a commercial extension that builds on top of the OSS Edition and adds modules and plugins, enabling an optimized work flow. The highlights of this edition are:

DBDoc provides the following features:

A comparison of edition features can be found at MySQL Workbench Developer Central. 

MySQL Workbench is available for the following platforms:

Binary distributions of MySQL Workbench are available for the preceding platforms. Source code distributions are also available as a tar.gz package or an RPM package.

The following sections explain the installation process for each of these platforms.

Advantages Of An ODBMS

We can list some of the advantages that we have found in using an ODBMS environment for a website.

Simplicity
We have no doubt that the simplicity of using an ODBMS contributes significantly to our ability to rapidly develop and deploy new functionality and bug fixes. It is extremely straightforward to create and persist Abstract Data Types, since the persistence mechanism directly supports classes and objects, requiring no extra work to map classes to tables (as required by an RDBMS implementation). An ODBMS also directly supports inheritance, which means that no difficult design decisions have to be made regarding the splitting of instance variable storage across tables.
Development cycles are measured in weeks and days - not the months that have typically been the case in many projects that we have worked on. In our opinion much of our efficiency can be attributed to our use of a Java ODBMS. The transactional model of the ODBMS is easy to understand, there is no database language syntax to learn, over and above that of the implementation language. Developers do not need to
use another language to express the database schema, because the Object Model as defined by the Java application classes is the schema.

Schema Management
The persistent Object Model is identical to that of the application class hierarchy. Managing a persistent Object Model is far simpler than managing an environment where the in memory structures are different than those on disk. However, care must be taken in designing the entry points to the large collections of root objects in the system. Less experienced developers often err in creating multiple root objects for the same underlying tree of objects, leading to confusion and incoherency in the model.

Code Independence
We have found that the completely non-invasive transactional model makes it possible to insulate most business objects in the system from having any knowledge of the underlying database. This is important in the event that we might have to migrate to some other environment at a later stage.
Knowledge of the persistence mechanism system is encapsulated in 27 of the 1000 (or so) application classes. While some O/R mapping environments will allow for a clean separation of this knowledge, many OO systems making use of an RDBMS must directly embed knowledge of SQL and tables deeply in the application classes themselves.
It is important to clarify the above point, no-where in our system does any object have to actively participate in the mechanism used to persist it. This is often the case in either purchased or home-grown O/R mapping frameworks, since classes need to have some knowledge
of what tables they fit in. It is only due to the fact that objects are persisted as objects and not fragmented into various atomic database types that this is possible. The knowledge of the persistence mechanism that is embedded in the 27 or so “aware” classes is purely related to obtaining connections to the database and management of database specific transactional mechanisms.

Natural Object Model
In an environment that uses an ODBMS, objects that refer to other objects always “contain” the object that they reference. What we mean by this is that there is no distinction between an “in-memory” object and an “on disk” object. In systems that make use of an RDBMS, objects are often found to contain a key or an index to the referenced object. Once again, some O/R mapping environments remove this complexity but more often than not, the fact that the referenced object is not actually stored as an object leaks through into the Object Model. Objects are always objects in the ODBMS model, and are always available. This naturalness of expression for the developer as well as the designer is very difficult to achieve in any RDBMS environment.

Collections
Many ODBMS vendors provide highly optimized Collection classes that can be used to provide efficient management of vast numbers of objects. Iteration over (and management of) the collections is straightforward and can be used without any complicated setup routines. We believe this is a distinct advantage to developers.

Performance
Performance is vital to the online experience, online users expect snappy responses. Some architects believe that doing things in a pure OO manner leads to poor performance. In many situations involving the storage and retrieval of objects, an ODBMS does deliver significant performance gains over other persistence mechanisms. We hasten to add that there are some instances when an RDBMS will outperform an ODBMS. These instances often occur when it is
necessary to perform arbitrary queries over large collections of objects.

Design Recovery (quickly and easily correct design mistakes)
By this odd term we mean the ability to quickly and easily correct design mistakes in the class hierarchy/ schema. Since the schema of the database is the class hierarchy as defined by the Java classes in the system, changing a class definition to correct a mistake in design or implementation is relatively simple.
In systems where there is a distinction between the class hierarchy and the database schema correcting flaws can become a complicated matter. Because the schema of an RDBMS is available to other modules (possibly developed outside of the scope of the larger system) errors are often introduced when making changes to the database structure. Changes to the RDBMSs schema may differ from the expectations of external programs. Such conflicts cannot occur in a true ODBMS since there is no difference in structure between in-memory in-use instances and those persistently stored on disk. There are however other problems that can occur when changing schemas.

Retention of Objects
Developers make mistakes. In an RDBMS these mistakes may occasionally lead to situations where inadvertently deleting a row in a table can lead to dangling references, since triggers are often imperfectly implemented. An ODBMS with Garbage Collection based object removal completely eliminates this problem. Persistent objects are only “deleted” once they are no longer referenced by any other instances reachable from a well-defined root object. The ability to recover from an accidental deletion has often allowed system to recover gracefully from potentially embarrassing situations. This has occurred when flawed code eliminates the primary reference to an object. Because other objects still referenced the “deleted” object, it was possible to restore the reference and thus recover the object. Obviously this only works if a persistent Garbage Collection has not been performed.

The hospital database should be implemented on a relational DBMS that are protected from user access both by the permissions on directories containing the database files and the permissions on the database files themselves. Users cannot look at the files in the database except through DBMS and its protection scheme; that is users cannot access the database at the operating system level. Additional binary files with special format are included, making decoding of any information more difficult. Moreover, DBMS has a built-in hierarchical security system. The database administrator (D.B.A.) controls the types of access allowed to various levels of users using this system.

The security labels which were defined during the secure conceptual design phase were implemented using the notions of roles and groups supported by DBMS. The user roles handled in our implementation are: doctor, normal nurse, and special nurse. The notion of user roles was implemented using the notion of user groups, provided by DMBS (a group is an identifier that can be used to apply permissions to a list of DBMS
users associated with the identifier). After performing a study on the considered users roles, the following clearances were assigned to them: clearance level 3 to the user role doctor, clearance level 2 to the user role special nurse, and clearance level 1 to the user role normal nurse.

The data sets loaded on the hospital database are: the nurse record, the doctor record, the patient record, which contains the medical information, the laboratory information, the follow-up information and the personal patient information. Being a relational database management system, DBMS stores data in tables. The labelling of the data sets was described above. However, it can change dynamically, if one of the security
constraints is satisfied, leading to upgrading and/or fragmentation. The classification level of each tuple of a table was implemented by adding at each table a column. This column contained the tuple classification; that is 1,2,3 instead of confidential, secret, top secret. Zero (0) indicates that the data contained in the tuple is cover story. Of course, the tuple class data was only visible to the D.B.A.

Apart from that, an additional column was added to the related medical data tables, containing the flag ‘h’ (history) or ‘l’ (last). This flag was automatically updated, when new relevant data was inserted. This is one of the integrity constraints that were implemented in the database.

Users were allowed to have access to the data only trough predefined forms. An DBMS form is the electronic equivalent of a paper form; it is displayed on the computer screen and is used for data input and data display. Forms consist of trim, text that provides helpful information, and fields. The latter display the data and accept data entry.

The access types supported from the secure prototype application are insert, read, update, execute, cancel. Thus, the possibility of deleting information is excluded. This was necessary, not only for reasons of better control of the information flow, but also for reducing the possibility of fatal mistakes.

The security constraints defined earlier were implemented using rules and procedures written in SQL.

A hospital, with health care information systems is one case of a security critical environment. It is one of the few environments, in which a confidentiality breach, wrong information or even a relatively minor loss of access to information may be life-threatening. Security is therefore an important issue which encompasses all aspects of the organization, from patient and staff safety to deeply personal information about staff and patients that is distributed throughout the organization. Due to the widespread use of the database technology, database security plays today a significant role in the overall security of health care information systems.

The development of a secure database for health care information system requires an appropriate multiphase design methodology which will guide the steps of the development and will provide tools supporting the automatic execution of some steps. The proposed methodology and security policy helps ensure all three aspects of security (secrecy, confidentiality and availability), without introducing significant overheads. It is based on the integration of mandatory and discretionary security policies and takes security into consideration from the very first steps of the design.
The choice of an appropriate security policy and a suitable secure database design methodology is crucial in each of health care environments. The two most well known proposals for the database security policies are the mandatory and the discretionary ones. Discretionary security policies govern the access of users to the information on the basis of the user’s identity and the rules specifying, for each user and each object in the system, the types of access the user is allowed on the object. Discretionary security policies are flexible and suitable for a variety of implementations. However, they provide insufficient control of the information flow (e.g. they are vulnerable to malicious attacks such as the Trojan Horses). On the other hand, mandatory security policies provide a high level of certification for security, based on the use of unforgeable security labels, which are assigned both to users and data. Thus, they allow one to track the flow of information. They are however mainly suitable to certain kinds of environments where the users and the objects can be easily classified (i.e. the military one).
None of these two major policies are sufficient by itself to cover the security needs of the health care environments. Hence, it has been necessary to propose a new security policy, which has been based on the integration of mandatory and discretionary control policies. In order to maximize the effectiveness and decrease the complexity of implementing this policy, a step by step design methodology with integrated security has been proposed. In particular, the responsibility of the role in the application determines the security label (clearance) of the user role. The security label (classification) of the data represents its level of sensitivity. The user roles are assigned a node at the user role hierarchy (URH). Then, beginning from the lower level of the hierarchy, the data items are assigned a security label equal to that of the users that must be cleared to access it. In the end, the security requirements are examined. This may lead to fragmentation of some relations and/or upgrading (since we support tuple level granularity). It must be noted that polyinstantiation - which is a characteristic of the multilevel security policy - is supported only in the form of cover stories. This is possible, due to the support of the write down mechanism (with no fear of inference), which is essential for the hospital environment.

Data mining aims at discovering novel, interesting and useful knowledge from databases. Conventionally, the data is analyzed manually. Many hidden and potentially useful relationships may not be recognized by the analyst. Many organizations including modern hospitals are capable of generating and collecting a huge amount of data.

Data stored in medical databases are growing in an increasingly rapid way. Analyzing that data is crucial for medical decision making and management. It has been widely recognized that medical data analysis can lead to an enhancement of health care by improving the performance of patient management tasks. There are two main aspects that define the need for medical data analysis.

For these purposes, the increase in database size makes traditional manual data analysis to be insufficient. New research fields such as knowledge discovery in databases (KDD) have rapidly grown in recent years. The main step in the knowledge discovery process, called data mining, deals with the problem of finding interesting regularities and patterns in data.

A simple data mining process model mainly includes 6 steps:

At a hospital we find daily activity correspond to medical treatment and other health care business. For example some patients come to internist get some medicine or just routine health check up, some physician get busy treating emergency patient at emergency room, at another place the patient's family go to cashier for paying the bill, etc. It is critical to understand the benefits and limitations of using these large-scale administrative databases. From an evidence-based medicine perspective, these data are important for generating hypotheses but not cause and effect relationships. In other words, the data itself are not specifically collected to address a clinical question, but rather represent a quality assurance process.

The phrase, ‘hospital information system’, is frequently used in discussions about the flow of information throughout a hospital with the assumption that everybody has the same concept in mind. Closer examination shows that this is not necessarily the case. 

Many organizations including modern hospitals are capable of generating and collecting a huge amount of data. This explosive growth of data requires an automated way to extract useful knowledge. Thus, medical domain is a major area for applying data mining. Through data mining, we can extract interesting knowledge and regularities. The discovered knowledge can then be applied in the corresponding field to increase the working efficiency and improve the quality of decision making.

Nowadays, data stored in medical databases are growing in an increasingly rapid way. Analyzing that data is crucial for medical decision making and management. It has been widely recognized that medical data analysis can lead to an enhancement of health care by improving the performance of patient management tasks. There are two main aspects that define the need for medical data analysis.

1. Support of specific knowledge-based problem solving activities through the analysis of patients’ raw data collected in monitoring.
2. Discovery of new knowledge that can be extracted through the analysis of representative collections of example cases, described by symbolic or numeric descriptors.