Question

TCO 2) Explain the purpose of a conceptual database model and describe the most common method of creating one

Answer 1

The Conceptual Data Model

A conceptual data model is a high level or coarse data model which is preliminary in structure, possibly abstract in content and sparse in attributes, that is intended to represent a business area. It is preliminary in structure because it may contain many-to-many relationships. It is abstract in content because it may need to suppress some details so as to subsume different subtypes. It is sparsely attributed because it will usually contain only major business attributes. Because of these characteristics, you cannot implement a conceptual data model.

There are three main reasons:

    For management presentations. If you have to justify or explain a project to management, you do not have forever. Management has a short attention span. This is not a value judgment about management. If you are presenting to senior, or any non-technical management, you need to get to the point in (say) 15 minutes or so. You have to be able to explain the issue to them clearly and quickly. A conceptual data model is ideal for this purpose. For this reason, the conceptual data model should fit on a single page.
    For planning. A project that is in the planning stages does not need detail yet. You need only know what overall data, and sometimes only what types of data, are contained in the business area. A mass of detail is not necessary for this. The conceptual data model serves this purpose.
    To start top-down modeling. There are two circumstances for which a conceptual data model is necessary: new development and major maintenance. New development is development from scratch. Only about 20% of software projects are new development. It is dangerous and cumbersome to do new development only bottom-up. In major maintenance substantial new requirements are added to an existing system. Such projects will start bottom-up when reverse engineering the existing database. The conceptual data model will be necessary to understand in what way to introduce the new requirements.

Let us expand our thoughts on bottom-up in data modeling. Use-case modeling is very popular these days. Use-cases are a simplified form of process modeling and an enriched form of process definition. It is helpful to employ use-cases to expand a data model. BUT the data model should not rely exclusively on use-cases. All data modeling should always be a combination of top-down, bottom-up and middle-out. New development starts top-down. Maintenance starts bottom-up. Developing a data model exclusively from use-cases is essentially doing a data model bottom-up. It restricts the kind of creative thinking that should naturally go into a data model. The conceptual data model is used to start the top-down process. The use-cases provide the bottom-up perspective. Working with the data model in and of itself, exploring business needs, and then expanding the data model from within is the middle-out part of the process. It is where the real creativity occurs. The data modeler and use-case modeler should be simultaneously exposed to requirements from the business experts. Then, individually, each develops its own unique deliverable from these; the data model in one case, the use-case in the other. And then these two models should be concurrently interacted and balanced one against the other.