What is a Database?

Database terminology is almost as slippery as the term "object-oriented programming". The word database can be used to describe everything from a single set of data, such a telephone list, to a complex set of tools, such as MySQL Server, and a whole lot in between. Although relational databases don't have real-world analogies, most are intended to model some aspect of the real world. I'll call that bit of the real world the problem space. The problem space, by its nature, is messy and complex- if it weren't, we wouldn't need to build a model of it. But it is critical to the success of your project to limit the database system you're designing to a specific, well-defined set of objects and interactions; only by doing so can you make sensible decisions about the scope of your system. I'll use the term data model to mean the conceptual description of the problem space. This includes the definition of entities, their attributes (a Customer, for example, is an entity, and it might have the attributes Name and Address), and the entitiy constraints on those relationships-for example, managers are not allowed to have more than 5 individuals reporting to them. It does not include any reference to the phisical layout of the system. The definition of the phisical layout - the tables and views that will be implemented - is the database schema or just schema. It's the translation of the conceptual model into a phisical representation that can be implemented using a database management system. Take note that the schema is still conceptual, not phisical. The schema is nothing more than the data model expressed in terms that you will use to describe it to the database engines - tables and triggers and such creatures. One of the benefits of using a database engine is that you don't ever have to deal with the physical implementation. Once you've explained to the database engine what you want the data to look like, using either code or an interactive environement such as Microsoft Access, phpMyAdmin, the engine will create some physical objects (usually, but not always, on a hard disk someplace) and you'll store data in them. The combination of structure and data si what I'll refer to as a database. This database includes the physical tables, the defined views, queries, and stored procedures; and the rules the engine will enforce to protect the data. The term "database" does not include the application, which consists of the forms and reports with which your users will interact, nor does it include any of the bits and pieces - things such as middleware of Microsoft Transaction Server - used to stick the front and back ends toghether. The term database also excludes the database engine. Thus, an Access .mdb file is a database, while Microsoft Jet is a database engine. Actually, an .mdb file can contain other things besides the database - forms and reports, for example. To describe all these components - the application, the database, the database engine, and the middleware - I'll use the term database system. All of the software and data that goes into making a production system is part of the datbase system. In the next article I will discuss The Relational Model. Freelance Programming