Database of Scriptum

In the development of the hospital information system would be better if done through a modularization into several sub-systems. For example, in this paper we split into the following subsystems:
- Personlia
- Registration of patients coming
- Outpatient and / or ER
- Radiology and Laboratory Examination
- Inpatient
- Pharmacy

- Cashier
Modularization aims to facilitate the management of the hospital information system to be developed. By splitting a large and complex systems into simpler sub-systems will certainly be developed by several different teams at the same time, which would certainly speed up the development process. Surely that must be considered is the integration of sub-systems are interconnected.
Of the sub-system that we have designed the above will be used to construct an appropriate database schema. Each sub-system is expected to be made of the database schema, and will be even better, for further development, if in each sub-system create the database schema on each server hardware.
In an upcoming article, we try to create a database schema for above sub systems using MySQL Workbench.

A naming standard is a collection of rules, which, when applied to data, results in a set of data objects named in a logical and standardized way. These names convey some information about the named objects; an element name, for example, indicates the set of possible valid values (its data domain), and its usage. Having naming standards helps to achieve efficient use and reuse of data through better understanding of what data is in the system. Standardized names enhance communications about data within the BI community, from source application developers to BI experts to end users.

These standards apply to database objects created explicitly for Business Intelligence. Use reasonably meaningful names for tables and fields. If they get too long then try to use fairly standard (but consistent) abbreviations. If in doubt, just remove the vowels (a, e, i, o, u).
For each table also have a three letter acronym. Then if you have an 'ID' field that is used in foreign key relationships, then put the three letter acronym before the '_ID' name in ALL the tables that use it including the owning table.

Develop a list of standard suffixes, for example:
_FL for flags (usually only Y and N)
_IND for indicators (typically single byte varchar2 fields)
_NO for numeric numbers
_NUM for character numbers
_DT for dates
_TS for date-time stamps
 

If you have a set of tables that are closely related then SERIOUSLY consider giving them the same prefix or name root.

As far as object naming standards go, the advice above is as good as any. Most important is to BE CONSISTENT. Google "Database Naming Standards" and look at some of the documents you find - especially those on domains with .edu. - universities are red-hot on this sort of thing.
Also search for Oracle Database Design Standards, or variants of that phrase. Someone has done this already and will have published them on the web. 

In general, the flow of services in a hospital is like this, first a patient comes in to register for the examination of physicians in ambulatory care or emergency services. Patients who had taken care of at the hospital will certainly use the medical record number previously used by the patient, while the patient who first came to the hospital services is going to get a new medical record number. At the time of enrollment to obtain health care, the patient receives a unique registration number.

Furthermore, patients who have registered earlier will be waiting in line queue in outpatient services to be handled by the appropriate physician, or if the patient signed up for emergency services must be immediately examined by a physician in the emergency services and other medical personnel.

In the next stage, doctors in ambulatory care or emergency care earlier may require further examination in clinical laboratory services or radiology services. This is certainly an attempt to confirm the diagnosis of the patient. The results of the examination in clinical laboratory services or radiology services will soon be given to the doctor, and then the doctor will give the patient the drug therapy.

After stage ambulatory care and emergency services to the clinical laboratory and radiology examinations and drug therapy is considered adequate, then there are two possibilities for a patient to move to the next stage. Two possibilities are patient immediately make payment at the cashier or, on the advice of the doctor patient continued to inpatient services.

From the description above it can be seen that the system of hospital services can be broken down into several sub-systems are interconnected. Sub system include patient registration system, the system in the outpatient, emergency service systems, systems in clinical laboratory services, radiology services system, a system in pharmacy services, payment systems at the checkout. Each of these sub-systems and sample preparation of the database schema will be discussed in further discussion.

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.