Database design: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 55: | Line 55: | ||
*[[POFN]] ([[Principle of Full Normalization]] |
*[[POFN]] ([[Principle of Full Normalization]] |
||
*[[The Third Manifesto]] |
*[[The Third Manifesto]] |
||
*[[Concept mapping]] |
|||
*[[Data modeling]] |
|||
*[[Entity-relationship model]] |
|||
*[[Object-relationship modelling]] |
|||
*[[Object role modeling]] |
|||
*[[Knowledge representation]] |
|||
*[[Logical data model]] |
|||
*[[Mindmap]] |
|||
*[[Ontology (computer science)|Ontology]] |
|||
*[[Physical data model]] |
|||
*[[Semantic Web]] |
|||
*[[Three schema approach]] |
|||
{{DEFAULTSORT:Database Design}} |
{{DEFAULTSORT:Database Design}} |
||
[[Category: |
[[Category:Computer]] |
||
[[de:Datenbankdesign]] |
[[de:Datenbankdesign]] |
Revision as of 03:55, 1 May 2010
Database design is the process of producing a detailed data model of a database. This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can used to describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. In the relational model these are the tables and views. In an object database the entities and relationships map directly to object classes and named relationships. However, the term database design could also be used to apply to the overall process of designing, not just the base data structures, but also the forms and queries used as part of the overall database application within the database management system (DBMS).
Design process: The process of doing database design generally consists of a number of steps which will be carried out by the database designer. Not all of these steps will be necessary in all cases. Usually, the designer must:
- Determine the relationships between the different data elements
- Superimpose a logical structure upon the data on the basis of these relationships.
Within the relational model the final step can generally be broken down into two further steps, that of determining the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information, or objects. This step is not necessary with an Object database.
The tree structure of data may enforce a hierarchical model organization, with a parent-child relationship table. An Object database will simply use a one-to-many relationship between instances of an object class. It also introduces the concept of a hierarchical relationship between object classes, termed inheritance
Determining data to be stored
In a majority of cases, a person who is doing the design of a database is a person with expertise in the area of database design, rather than expertise in the domain from which the data to be stored is drawn e.g. financial information, biological information etc. Therefore the data to be stored in the database must be determined in cooperation with a person who does have expertise in that domain, and who is aware of what data must be stored within the system.
This process is one which is generally considered part of requirements analysis, and requires skill on the part of the database designer to elicit the needed information from those with the domain knowledge. This is because those with the necessary domain knowledge frequently cannot express clearly what their system requirements for the database are as they are unaccustomed to thinking in terms of the discrete data elements which must be stored. Data to be stored can be determined by Requirement Specification.
Types of Database design:
Conceptual schema
Once a database designer is aware of the data which is to be stored within the database, they must then determine where dependancy is within the data. Sometimes when data is changed you can be changing other data that is not visible. For example, in a list of names and addresses, assuming a situation where multiple people can have the same address, but one person cannot have more than one addresses, the name is dependent upon the address, because if the address is different than the associated name is different too. However, the other way around is different. One attribute can change and not another.
(NOTE: A common misconception is that the relational model is so called because of the stating of relationships between data elements therein. This is not true. The relational model is so named because it is based upon the mathematical structures known as relations.)
Logically structuring data
Once the relationships and dependencies amongst the various pieces of information have been determined, it is possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the database management system. In the case of relational databases the storage objects are tables which store data in rows and columns.
Each table may represent an implementation of either a logical object or a relationship joining one or more instances of one or more logical objects. Relationships between tables may then be stored as links connecting child tables with parents. Since complex logical relationships are themselves tables they will probably have links to more than one parent.
In an Object database the storage objects correspond directly to the objects used by the Object-oriented programming language used to write the applications that will manage and access the data. The relationships may be defined as attributes of the object classes involved or as methods that operate on the object classes.
Physical database design
The physical design of the database specifies the physical configuration of the database on the storage media. This includes detailed specification of data elements, data types, indexing options and other parameters residing in the DBMS data dictionary. It is the detailed design of a system that includes modules & the database's hardware & software specifications of the system.
References
![]() | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (April 2009) |
Further reading
- S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. ISBN 0-12369389-6
- T. Teorey, S. Lightstone, T. Nadeau, “Database Modeling & Design: Logical Design, 4th edition”, Morgan Kaufmann Press, 2005. ISBN 0-12-685352-5
- Practical tips on everyday's Database Design, 2004/2005, The Database Design Guide
External Links:
- [Database]
See also
- POOD (Principle of Orthogonal Design)
- POFN (Principle of Full Normalization
- The Third Manifesto
- Concept mapping
- Data modeling
- Entity-relationship model
- Object-relationship modelling
- Object role modeling
- Knowledge representation
- Logical data model
- Mindmap
- Ontology
- Physical data model
- Semantic Web
- Three schema approach