Logical Data modeling

Sayyan.N Shaikh 4SN11MAR10 IAR,M-Tec

Introduction
The sole purpose of an Information System is to support or automate business activities by storing and processing relevant business information or data. It is therefore critical to the success of any IS development that the meaning, structure and business rules of the required data are fully analysed, understood and modelled. During the Investigation phase we are concerned with understanding the underlying (i.e. logical) data requirement rather than making decisions about its physical implementation.

Current and Required Data

Most of the data required for the future system will be the same in content or meaning as that used currently. The other form of data analysis concerns requirements for new business data. The approach of starting with an analysis of existing data will provide the most rigorous and efficient approach. This approach will also help in driving out restrictions in data support arising from existing technical constraints.

Physical vs Logical Data Structures

An organisations data will be physically stored in many different places, e.g. paper files, computer files. This data will almost inevitably contain duplications and compromises due to the physical restrictions of storage, processing or practicality. Example: A physical purchase order form will hold information about products (product name, product number, product price), suppliers (supplier name, supplier address), the orders heading (purchase order number, purchase order date) as well as the quantity of each product ordered (quantity ordered).

 In other words the underlying logical view is of a number of separate data groupings, each describing a different business concept or object. We will also find that information on, for example, products is physically held in many other places, such as on customer orders, invoices and despatch notes. This all leads to a confusing mess of duplication and interconnecting information, which in turn leads to problems in maintaining data consistency and integrity.

The Logical Data Model

In system modeling the vehicle for analysing the logical structure of an organisations information is the Logical Data Model (LDM). A Logical Data Model is a way of graphically representing what that information is really all about, how it relates to other information and business concepts, and how business rules are applied to its use in the system. The LDM is possibly the most important and ultimately the most rigorous product of an entire data base.

Logical Data Models consist of two parts:

a diagram called the Logical Data Structure (LDS); a set of associated textual descriptions that explain each part of the diagram.

Entities
Any object or concept about which a system needs to hold information is known as an Entity Type (or entity for short). To be a valid entity we must wish to hold information on more than one occurrence of it. Entity occurrences are real world instances of an entity type. For example the entity type Supplier will have occurrences such as:

Entities (continued)
The symbol for an entity in an LDS is a round cornered rectangle containing the entitys name (which must be unique):
Supplier unique name

An entity must have a number of properties to qualify as such: - There must be more than one occurrence of the entity. - Each occurrence should be uniquely identifiable. - There must be data that we want to hold about the entity. - It should be of direct interest to the system.

Attributes
Each item of information (or data) that we hold about an entity is known as an attribute or data item. Examples of attributes for Supplier might be supplier number, supplier name, supplier address, and supplier telephone no. The detail of an entitys attributes is not formally included on the Logical Data Structure itself. This is held in separate textual descriptions.

Relationships
Entities do not exist in isolation, but are related to other entities. In physical data structures these relationships are signified by physical links such as pointers or placement in the same file or document. In logical models relationships represent business associations or rules and not physical links. Any entities that are related are linked by a line on the LDS. The line is labelled with the name of the relationship, and is named in both directions.

Degree
The number of occurrences of each entity type participating in a given relationship is denoted by the degree or cardinality of that relationship, and illustrated on the LDS by adding crows feet to the relationships line. There are three types of degree:
Many to Many (m:n). This tells us that each occurrence of A is related to one or more occurrences of B, and each occurrence of B is related to one or more occurrences of A. One to Many (1:m). This tells us that each occurrence of A is related to one or more occurrences of B, but each occurrence of B is related to only one occurrence of A. One to One (1:1). This tells us that each occurrence of A is related to only one occurrence of B, and each occurrence of B is related to only one occurrence of A.

Developing the LDS

To start with we are only interested in producing a high level model of the current systems underlying data structure. Due to its largely conceptual nature Logical Data Modelling can be one of the most intense activities of an System Data Modeling project. In many projects development of the LDM is started by holding brainstorming sessions with small groups of analysts and users. With a little practice analysts often find that the best method of data modelling is to draw up possible LDSs almost instinctively Relationships are added as each entity is identified and then checked with users on the spot. This approach has a lot to recommend it, particularly at this level of detail or for small systems, as diagrams are produced and verified quickly.

Identifying Entities
To identify entities in the current environment we can begin by looking at our physical data stores to find out exactly what it is that they hold information about. If we take the customer order file and discuss it with users, we find that it not only contains details of each individual order, but of the customers themselves,
i.e. customer address, customer telephone number etc., and so encompasses at least two entities, namely Customer and Customer Order.

Verification

Once the entity list has been drawn up we should verify it with key users during preliminary scoping interviews. The key questions to ask of each entity are: Are any of the candidates merely attributes of another entity? Do any of the candidates represent a subset of occurrences of another entity? Do all of the entities have a unique identifier? During this process we may discover new entities, merge existing entities or discard candidates as being outside the area of investigation.

Adding Relationships
We now examine each entity to see if it is directly related, in a way that is of interest to the system, to any of the other entities. The best way to do this is in discussion with users, either taking each entity in turn, or starting with a key entity and moving around the LDS network as the relationships are identified. Having identified where we think relationships exist, we now consider their degree, optionality and names. We do this by identifying the business rules that apply to each entity pairing. The basic process is the same for all pairings, so we will look at just one example.

Validating the LDM

we need to check that the LDM can provide access to all of the data items required by each update or enquiry process. Most processes will need to access a number of data items, which will be specified by some selection criteria. These items will often be represented by the attributes of more than one entity. navigate around the relationships of the LDS, applying the selection criteria to filter out the entity occurrences we need to provide all of the necessary data. These navigations are called Access Paths.

QUESTIONS???

THANK YOU