Database

A database consists of an organized collection of data for one or more uses, typically in digital form. One way of classifying databases involves the type of their contents, for example: bibliographic, document-text, statistical. Digital databases are managed using database management systems, which store database contents, allowing data creation and maintenance, and search and other access.

Database Management System

A database management system (DBMS) consists of software that operates databases, providing storage, access, security, backup and other facilities. Database management systems can be categorized according to the database model that they support, such as relational orXML, the type(s) of computer they support, such as a server cluster or a mobile phone, the query language(s) that access the database, such as SQL or XQuery, performance trade-offs, such as maximum scale or maximum speed or others. Some DBMS cover more than one entry in these categories, e.g., supporting multiple query languages.Examples of some commonly used DBMS are MySQL, PostgreSQL, Microsoft Access, SQL Server, FileMaker,Oracle, RDBMS, dBASE, Clipper,FoxPro,etc. Almost every database software comes with an Open Database Connectivity (ODBC) driver that allows the database to integrate with other databases. A DBMS is a set of software programs that controls the organization, storage, management, and retrieval of data in a database. DBMSs are categorized according to their data structures or types. The DBMS accepts requests for data from an application program and instructs theoperating system to transfer the appropriate data. The queries and responses must be submitted and received according to a format that conforms to one or more applicable protocols. When a DBMS is used, information systems can be changed more easily as the organization's information requirements change. New categories of data can be added to the database without disruption to the existing system. Database servers are dedicated computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with generous memory and RAID disk arrays used for stable storage. Hardware database accelerators, connected to one or more servers via a high-speed channel, are also used in large volume transaction processing environments. DBMSs are found at the heart of most database applications. DBMSs may be built around a custom multitasking kernel with built-in networking support, but modern DBMSs typically rely on a standard operating system to provide these functions.

File Based System

A file based system is a collection of application programs that perform services for the users wishing to access information. Each program within a file based system defines and manages its own data. Because of this, there are limits as to how that data can be used or transported.

File based systems were developed as better alternatives to paper based filing systems. By having files stored on computers, the data could be accessed more efficiently. It was common practice for larger companies to have each of its departments looking after its own data. The problems that arise with this type of file based system are listed below: - Data separation and isolation - Data dependence - Data duplication - Incompatible data (different file formats) - Lack of flexibility in organising and querying the data - Increased number of different application programs Some advantages of database systems are outlined below: - Sharing of data - Consistency of data - Integrity of data - Security of data - Data independence - Allows for more analysis of the same amount of data - Improved data access and system performance - Potentially increased productivity - Increased concurrency - Improved data backups and recovery Some potential disadvantages of database systems are the cost of implementing them, the amount of effort needed to transfer data into the database from a current system, and also the impact on the whole company if the database fails (even if only for a relatively short period).

Manual System
Manual database is very slow and clumbsy, not reliable (in the sense you can lose file records) like filing in a cabinet. Unlike a computerized database which is stored in a computer. It is very fast, well organized information, and grouped related data. It is more reliable as you can recover it whereas manual database cannot be recovered.

Data Model
A data model is used to organize data. A data model captures the cardinality and referential integrity rules needed to ensure that the data is of good quality for the users. A data model has 3 uses in an application which are getting data in, integrating data and getting data out. A data model is also used as a communication tool for teams to communicate within the team on how data is organized and between teams.

Business Rules and Example

A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern the project are atomic -- that is, they cannot be broken down further. Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals. For example a business rule might state that no credit check is to be performed on return customers. Other examples of business rules include requiring a rental agent to disallow a rental tenant if their credit rating is too low, or requiring company agents to use a list of preferred suppliers and supply schedules. While a business rule may be informal or even unwritten, writing the rules down clearly and making sure that they don't conflict is a valuable activity. When carefully managed, rules can be used to help the organization to better achieve goals, remove obstacles to market growth, reduce costly mistakes, improve communication, comply with legal requirements, and increase customer loyalty. A business rule is just as it states. Lets take a look at a really simple example first; Let say for example a business has a RULE that on its web site when you are filling out a form that the First Name field can only contain 20 characters, thats the rule! In the database you would apply a constraint (some might do this at program level) that permits the First Name field to only contain 20 character. Now business rules typically go MUCH deeper than that. Business rules in an application, or program simply represent constraints or processes that you put in place in order to comply with the rules set out by the business. These rules can be corporate rules or simply limitations, or constraints that yield the appropriat outcome as setup in the scope of work (The technical document that tells you what your program needs to do, how it is to look, how end users are to interact with it, etc). Business rules tell an organization what it can do in detail, while strategy tells it how to focus the business at a macro level to optimize results. Put differently, a strategy provides high-level direction about what an organization should do. Business rules provide detailed guidance about how a strategy can be translated to action. Business rules exist for an organization whether or not they are ever written down, talked about or even part of the organizations consciousness. However it is a fairly common practice for organizations to gather business rules. This may happen in one of two ways.

Organizations may choose to proactively describe their business practices, producing a database of rules. While this activity may be beneficial, it may be expensive and time consuming. For example, they might hire a consultant to come through the organization to document and consolidate the various standards and methods currently in practice. More commonly, business rules are discovered and documented informally during the initial stages of a project. In this case the collecting of the business rules is coincidental. In addition, business projects, such as the launching of a new product or the re-engineering of a complex process, might lead to the definition of new business rules. This practice of coincidental business rule gathering is vulnerable to the creation of inconsistent or even conflicting business rules within different organizational units, or within the same organizational unit over time. This inconsistency creates problems that can be difficult to find and fix. Allowing business rules to be documented during the course of business projects is less expensive and easier to accomplish than the first approach, but if the rules are not collected in a consistent manner, they are not valuable. In order to teach business people about the best ways to gather and document business rules, experts in business analysis have created the Business Rules Methodology. This methodology defines a process of capturing business rules in natural language, in a verifiable and understandable way. This process is not difficult to learn, can be performed in real-time, and empowers business stakeholders to manage their own business rules in a consistent manner. Gathering business rules is also called rules harvesting or business rule mining. The business analyst or consultant can extract the rules from IT documentation (like use cases, specifications or system code). They may also organize workshops and interviews with subject matter experts (commonly abbreviated as SMEs). Software technologies designed to capture business rules through analysis of legacy source code or of actual user behavior can accelerate the rule gathering processing.

Entity
An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world. An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem.

Attributes
An attribute is a property or characteristic. In a database management system (DBMS), an attribute may describe a component of the database, such as a table or a field, or may be used itself as another term for a field. Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; theproved relationship may have a date attribute.

Relationship and Types

A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs.

An association established between common fields (columns) in two tables is called relationship. It is a fundamental concept of relational database. The entities have a set of properties associated with them. For example each student has a set of properties such as Roll no, Name, Fathers name, Address, Phone no etc. When we create tables associated with entities, the properties become fields of these tables. In a student table, each student has more than one phone numbers associated with him. Such association is also referred to as relationship.

There are three types of relationships. 1. One-to-one relationship 2. One-to-many relationship 3. Many-to-many relationship 1. One-to-One Relationship In one-to-one relationship, two tables are associated in such a way that each record in first table can have only one matching record in second table, and each record in second table can have only one matching record in first table. Consider the relationship between countries and their capitals given below.

2. One-to-Many Relationship In one-to-many relationship, two tables are associated in such a way that each record in the first table can have many matching records in second table, but a record in second table has only one matching record in first table. For example, the student table has unique records and each Roll_no instudent table may have more than one phone numbers in student phone table, on the other hand when you see records in student phone table, each record in. it has only one matching record in student table.

3. Many-to-Many Relationship In many-to-many relationship, two tables are associated in such a way that each record in the first table can have many matching records in second table, and a record in second table can have many matching records in first table.

Suppose two sisters are in the same school. The relationship between two entities is shown above. In the above relationship, each record in the left side has two records in right side. Similarly, each record in the right side has two related records in left side. Referential Integrity Referential integrity ensures that the relationships between records in related tables remain consistent For example; if the student table and student phone table are related then every record in student phone table has a corresponding record in the student table. The databasemanagement system will not allow you to delete record from the student table if there are phone numbers related to that student in the studentphone table.

Entity Relationship Diagram (ERD)

In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in atop-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. The definitive reference for entity-relationship modeling is Peter Chen's 1976 paper. However, variants of the idea existed previously,and have been devised subsequently.

The first stage of information system design uses these models during the requirements analysis to describe information needs or the type ofinformation that is to be stored in a database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design". There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation mainly relates to conceptual modeling. There are a range of notations employed in logical and physical database design, such as IDEF1X. Diagramming conventions Entity sets are drawn as rectangles, relationship sets as diamonds. If an entity set participates in a relationship set, they are connected with a line. Attributes are drawn as ovals and are connected with a line to exactly one entity or relationship set. Cardinality constraints are expressed as follows: a double line indicates a participation constraint, totality or surjectivity: all entities in the entity set must participate in at least onerelationship in the relationship set; an arrow from entity set to relationship set indicates a key constraint, i.e. injectivity: each entity of the entity set can participate in at most one relationship in the relationship set; a thick line indicates both, i.e. bijectivity: each entity in the entity set is involved in exactly one relationship. an underlined name of an attribute indicates that it is a key: two different entities or relationships with this attribute always have different values for this attribute. Attributes are often omitted as they can clutter up a diagram; other diagram techniques often list entity attributes within the rectangles drawn for entity sets.

Two related entities shown using Crow's Foot notation

Chen's notation for entity-relationship modeling uses rectangles to represent entities, and diamonds to represent relationships appropriate for first-class objects: they can have attributes and relationships of their own. Related diagramming convention techniques: Bachman notation EXPRESS IDEF1X[4] Martin notation (min, max)-notation of Jean-Raymond Abrial in 1974 UML class diagrams

Crow's Foot Notation Crow's Foot notation is used in Barker's Notation, SSADM and Information Engineering. Crow's Foot diagrams represent entities as boxes, and relationships as lines between the boxes. The ends of these lines are shaped to represent thecardinality of the relationship. Usage of Chen notation is more prevalent in the United States, while Crow's Foot notation is used primarily in the UK. Crow's Foot notation was used in the 1980s by the consultancy practice CACI. Many of the consultants at CACI (including Barker) subsequently moved to Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the notation to a wider audience. Crow's Foot notation is used by these tools: ARIS, System Architect, Visio, PowerDesigner,Toad Data Modeler, DeZign for Databases, Devgems Data Modeler, OmniGraffle, andMySQL Workbench. CA's ICASE tool, CA Gen aka Information_Engineering_Facilityalso uses this notation. ER diagramming tools There are many ER diagramming tools. Some free software ER diagramming tools that can interpret and generate ER models, SQL and do database analysis are MySQL Workbench, DBDesigner and Open ModelSphere (open-source). A freeware ER tool that can generate database and application layer code (webservices) is the RISE Editor. Some of the proprietary ER diagramming tools are ARIS, Avolution, Aqua Data Studio, dbForge Studio for MySQL, DeZign for Databases,ER/Studio, Devgems Data Modeler, ERwin, MEGA International, OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, Sparx Enterprise Architect, SQLyog, System Architect, Toad Data Modeler, SQL Maestro, Microsoft Visio, Visible Analyst, and Visual Paradigm. Some free software diagram tools just draw the shapes without having any knowledge of what they mean, nor do they generate SQL. These include Kivio and Dia. DIA diagrams, however, can be translated with tedia2sql.

Data flow diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through aninformation system. It differs from the flowchart as it shows the data flow instead of the controlflow of the program. A data flow diagram can also be used for the visualization of data processing (structured design). Data flow diagrams were invented by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "data flow graph" model of computation. It is common practice to draw a context-level Data flow diagram first which shows the interaction between the system and outside entities. The DFD is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts.

This context-level Data flow diagram is then "exploded" to show more detail of the system being modeled.

On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD).

Date Flow Diagrams are advantageous as: 1. It tracks any information entering or leaving the system. 2. It depicts how changes to information take place. 3. It represents how and in what form the information is getting stored. Date Flow Diagrams are generally used as a system modeling tool and for structured system analysis and design. To represent a program or a software system, Date Flow Diagrams are implemented in the software designing phase. Various levels of Data Flow Diagrams 1) Zero-level DFD or Context-level Data Flow Diagram This level basically represents the input and output of the entire system. 2) 1-level DFD The basic/care modules of the system are represented in this phase and how data mane gates through different modules is shown. 3) 2-Level DFD The module details are represented in this level. Therefore, detailed Data Flow Diagrams can be drawn with regard to the complexity of system.

Notations in DFDs Data Flow Diagrams show the passage of data through the system by using fine basic constructs. 1) Data Flow

It shows flow of data from a source to a destination. It is shown with an arrowed line with the arrowhead showing the direction of flow. It can move from an external entity to a process, from a process to another process, into and out of a store from a process, and from a process to an external entity as well. It should be noted that the Data flow cannot occur from external entity to a store or from a store directly to an external entity. 2) Processes: These are transformations which change incoming data flow into outgoing data flow. They are drawn in circular boxes:

The name of the process should describe what may happen to the data as it passes through the process. 3) Data/Stores It is repository of data, that is, a file or database It is represented by two parallel lines and between those lines name of data store is mentioned

4) External entities: They are external data processing units which represent some external process, outside of the regular data flow .They rely outside the system boundaries. 5) Resource store:

It represents process with resource flow. It represents flow of material than data. Example of Data Flow Diagrams Data Flow Diagram (Level-0 and Level-1) for an ATM system can be represented as

Advantages of Data Flow Diagrams It is a simplified but powerful graphic technique It enables representing data with different levels of details. It helps defining boundaries of the system

Level zero diagram (context diagram) and Example

This level basically represents the input and output of the entire system. It is common practice to draw a context-level data flow diagram first, which shows the interaction between the system and external agents which act as data sources and data sinks. On the context diagram (also known as the 'Level 0 DFD') the system's interactions with the outside world are modelled purely in terms of data flows across the system boundary. The context diagram shows the entire system as a single process, and gives no clues as to its internal organization.

Data flow diagram for an ATM System:

List and differentiate other used case tools

Database model A database model is a theory or specification describing how a database is structured and used. Several such models have been suggested. Common models include:

Flat model: This may not strictly qualify as a data model. The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another. Hierarchical model: In this model data is organized into a tree-like structure, implying a single upward link in each record to describe the nesting, and a sort field to keep the records in a particular order in each same-level list. Network model: This model organizes data using two fundamental constructs, called records and sets. Records contain fields, and sets define one-to-many relationships between records: one owner, many members. Relational model: is a database model based on first-order predicate logic. Its core idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values.

 Object-relational model: Similar to a relational database model, but objects, classes and inheritance are directly supported in database schemas and in the query language. Star schema is the simplest style of data warehouse schema. The star schema consists of a few "fact tables" (possibly only one, justifying the name) referencing any number of "dimension tables". The star schema is considered an important special case of the snowflake schema.

Data Structure Diagram

Example of a Data Structure Diagram.

A data structure diagram (DSD) is a diagram and data model used to describe conceptual data models by providing graphical notations which document entities and their relationships, and the constraints that binds them. The basic graphic elements of DSDs are boxes, representing entities, and arrows, representing relationships. Data structure diagrams are most useful for documenting complex data entities. Data structure diagrams are an extension of the entity-relationship model (ER model). In DSDs, attributes are specified inside the entity boxes rather than outside of them, while relationships are drawn as boxes composed of attributes which specify the constraints that bind entities together. The E-R model, while robust, doesn't provide a way to specify the constraints between relationships, and becomes visually cumbersome when representing

entities with several attributes. DSDs differ from the ER model in that the ER model focuses on the relationships between different entities, whereas DSDs focus on the relationships of the elements within an entity and enable users to fully see the links and relationships between each entity. There are several styles for representing data structure diagrams, with the notable difference in the manner of defining cardinality. The choices are between arrow heads, inverted arrow heads (crow's feet), or numerical representation of the cardinality. Geographic data model A data model in Geographic information systems is a mathematical construct for representing geographic objects or surfaces as data. For example, the vector data model represents geography as collections of points, lines, and polygons; the raster data model represent geography as cell matrixes that store numeric values; and the Triangulated irregular network (TIN) data model represents geography as sets of contiguous, nonoverlapping triangles.

Generic data model

Generic data models are generalizations of conventional data models. They define standardised general relation types, together with the kinds of things that may be related by such a relation type. Generic data models are developed as an approach to solve some shortcomings of conventional data models. For example, different modelers usually produce different conventional data models of the same domain. This can lead to difficulty in bringing the models of different people together and is an obstacle for data exchange and data integration. Invariably, however, this difference is attributable to different levels of abstraction in the models and differences in the kinds of facts that can be instantiated (the semantic expression capabilities of the models). The modelers need to communicate and agree on certain elements which are to be rendered more concretely, in order to make the differences less significant.

Semantic data model

A semantic data model in software engineering is a technique to define the meaning of data within the context of its interrelationships with other data. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. A semantic data model is sometimes called aconceptual data model. The logical data structure of a database management system (DBMS), whetherhierarchical, network, or relational, cannot totally satisfy the requirements for a conceptual definition of data because it is limited in scope and biased toward the implementation strategy employed by the DBMS. Therefore, the need to define data from a conceptual view has led to the development of semantic data modeling techniques. That is, techniques to define the meaning of data within the context of its interrelationships with other data. As illustrated in the figure. The real world, in terms of resources, ideas, events, etc., are symbolically defined within physical data stores. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. Thus, the model must be a true representation of the real world. Information model

Example of an EXPRESS G Information model.

An Information model is not a type of data model, but more or less an alternative model. Within the field of software engineering both a data model and an information model can be abstract, formal representations of entity types that includes their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network, or they may themselves be abstract, such as for the entities used in a billing system. Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations. According to Lee (1999) an information model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. It can provide sharable, stable, and organized structure of information requirements for the domain context. More in general the term information model is used for models of individual things, such as facilities, buildings, process plants, etc. In those cases the concept is specialised to Facility Information Model, Building Information Model, Plant Information Model, etc. Such an information model is an integration of a model of the facility with the data and documents about the facility. An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models (e.g. using UML), entity relationship models or XML schemas.

Document Object Model, a standard object model for representing HTML or XML.

Object model
An object model in computer science is a collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. For example, the Document Object Model

(DOM) is a collection of objects that represent apage in a web browser, used by script programs to examine and dynamically change the page. There is aMicrosoft Excel object model for controlling Microsoft Excel from another program, and the ASCOMTelescope Driver is an object model for controlling an astronomical telescope. In computing the term object model has a distinct second meaning of the general properties of objects in a specific computer programming language, technology, notation or methodology that uses them. For example, the Java object model, the COM object model, or the object model of OMT. Such object models are usually defined using concepts such as class, message, inheritance, polymorphism, andencapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages.

Object Role Model

Object Role Modeling (ORM) is a method for conceptual modeling, and can be used as a tool for information and rules analysis. Object Role Modeling is a fact-oriented method for performing systems analysis at the conceptual level. The quality of a database application depends critically on its design. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand. The conceptual design may include data, process and behavioral perspectives, and the actual DBMS used to implement the design might be based on one of many logical data models (relational, hierarchic, network, object-oriented etc.).

Unified Modeling Language models The Unified Modeling Language (UML) is a standardized general-purposemodeling language in the field of software engineering. It is a graphical languagefor visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The Unified Modeling Language offers a standard way to write a system's blueprints, including: Conceptual things such as business processes and system functions Concrete things such as programming language statements, database schemas, and Reusable software components. UML offers a mix of functional models, data models, and database models.

Sources:
http://www.computingstudents.com/notes/database_systems/database_file_based_systems.php http://en.wikipedia.org/wiki/Database http://en.wikipedia.org/wiki/Database_management_system http://it.toolbox.com/wiki/index.php/Entity_Relationship_Diagram http://wiki.answers.com/Q/In_database_design_what_is_a_business_rule http://www.businessrulesgroup.org/first_paper/br01c1.htm http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci214608,00.html http://en.wikipedia.org/wiki/Entity-relationship_model http://www.free-computer-tips.info/computer-software/types-of-database-relationships.html