Explain Database Schema and its Types
Explain Database Schema and its Types: A database schema is a skeleton structure that represents the logical view of the complete database. It defines how it is organized and the way the relations among them are associated. It formulates all the constraints that are to be applied to the information. A database schema defines its entities and also the relationship between them. It contains a descriptive detail of the database, which may be pictured by means of schema diagrams. It’s the database designers who design the schema to assist programmers to perceive the database and make it helpful.
Also See: Explain Database Architecture
Explain Database Schema and its Types
A database schema is categorized as below:
- Logical database schema
- Physical database schema
- View schema
- Logical Database Schema: This schema defines all the logical constraints that require to be applied on the information stored. It defines tables, views, and integrity constraints.
- Physical Database Schema: This schema pertains to the particular storage of information and it’s kind of storage like files, indices, etc. It defines how the information will be stored in an exceedingly auxiliary storage.
- View schema: View schema is outlined because of the style of a database at view level that usually describes end-user interaction with database systems.
It is vital that we have a tendency to distinguish these 2 terms separately. A database schema is that the skeleton of a database. It’s designed when the information does not exist in the slightest degree. Once the database is operational, it’s terribly tough to form any changes to that. A database schema doesn’t contain any information or data.
A database instance could be a state of an operational database with information at any given time. It contains a snap of the database. Database instances tend to alter over time. A software package ensures that its every instance (state) is in an exceedingly valid state, by diligently following all the validations, constraints, and conditions that the database designers have imposed.
Let suppose, you’re storing students’ data in a student’s table. At the physical level, these records are represented as chunks of storage (in bytes, gigabytes, terabytes or higher) in memory and these parts typically stay hidden from the programmers. Then comes the logical level; here in logical level these records are often illustrated as fields and attributes besides their information type(s), their relationship with one another are often logically enforced. Programmers usually work on this level as a result of their conscious of such things concerning database systems. At view level, a user will able to act with the system, with the assistance of interface and enter the details on the screen. The users don’t seem to be attentive to the actual fact how the information is held on and what data is stored; such details are hidden from them.
Another simple example of database schema:
Fig2: an example of a database schema
Detailed explanation on three layers of schema:
As we tend to came to grasp that there are 3 differing types of schema within the database and these are outlined consistently with the amount of abstraction of the three-level design delineated within the above figure1, at the very best level, there are multiple external schemas (view level schema) (also referred to as sub-schemas) that match up to totally different views of the information. At the abstract level, there’s the conceptual schema or the logical schema that describes all the entities, attributes, and relationships besides integrity constraints. At the bottom level of abstraction, there’s the interior schema or the physical schema that makes a whole description of the interior model, containing the classifications of keep records, the strategies of illustration, the information fields, storage structures used etc. it’s to be noted that there’ll be just one abstract schema and one internal schema per information. The package is liable for mapping between these 3 sorts of a schema.
Also See: Different Keys in Dbms
It should conjointly check the schemas for consistency; which suggests, the DBMS should ensure every external schema is derived from the conceptual schema and should use the data within the conceptual schema for mapping among those external schemas and also the internal schema. It conjointly permits any variations in entity names; attribute names, attribute order, data types, and so on, to be determined. Lastly, every external schema is expounded to the conceptual schema by the external/conceptual mapping. This allows the DBMS to map names within the user’s view on to the relevant a part of the conceptual schema.
So it was all about Explain Database Schema and it Types, if it help you then please share it with your friends.