HIGH LEVEL CONCEPTUAL DATA MODELS FOR DATABASE DESIGN
High-level conceptual data models serve as blueprints for designing
databases, focusing on the structure and organization of data rather than
technical implementation details. Here are some common conceptual data
models used in database design:
1. Entity-Relationship Model (ER Model):
Entities represent real-world objects or concepts.
Relationships describe how entities are related to each other.
Attributes represent properties or characteristics of entities.
ER diagrams visualize these components using entities,
relationships, and attributes connected by lines.
2. Unified Modeling Language (UML):
Widely used in software engineering, UML provides various
diagrams for visualizing different aspects of a system, including
data modeling.
Class diagrams depict classes (equivalent to entities), their
attributes, methods, and relationships.
Object diagrams show instances of classes and their relationships.
Use case diagrams illustrate the interactions between users and the
system.
3. Object-Role Modeling (ORM):
Focuses on capturing both data structure and business rules.
Key concepts include objects, roles, relationships, and constraints.
ORM diagrams depict objects (equivalent to entities), roles played
by objects, and relationships between them.
4. Hierarchical Model:
Represents data in a tree-like structure with parent-child
relationships.
Each parent can have multiple children, but each child can have
only one parent.
Commonly used in older database systems like IMS (Information
Management System).
5. Network Model:
Extends the hierarchical model by allowing each child to have
multiple parents.
Data is represented as records (equivalent to entities) linked
through pointers.
Offers more flexibility in modeling complex relationships compared
to the hierarchical model.
Roles in DBMS Environment, DBA Role, Database Designers
There are four distinct types of people that participate in the DBMS environment: data and
database administrators, database designers, application developers, and the end-users.
Data Administrators
The database and the DBMS are corporate resources that must be managed like any other
resource. The Data Administrator (DA) is responsible for defining data elements, data names
and their relationship with the database.They are also known as Data Analyst.
Database Administrators (DBA)
A Database Administrator (DBA) is an IT professional who works on creating, maintaining,
querying, and tuning the database of the organization. They are also responsible for
maintaining data security and integrity. A DBA has many responsibilities. A good performing
database is in the hands of DBA.
DBA Responsibilities
The life cycle of database starts from designing, implementing to administration of it. A
database for any kind of requirement needs to be designed perfectly so that it should work
without any issues.
Once all the design is complete, it needs to be installed. Once this step is complete, users start
using the database. The database grows as the data grows in the database. When the database
becomes huge, its performance comes down.
Also accessing the data from the database becomes challenge. These administration and
maintenance of database is taken care by database Administrator – DBA
.
Installing and upgrading the DBMS Servers
DBA is responsible for installing a new DBMS server for the new projects. He is also
responsible for upgrading these servers as there are new versions comes in the market or
requirement.
Design and implementation
He should be able to decide proper memory management, file organizations, error handling,
log maintenance etc for the database.
Performance Tuning
Since database is huge and it will have lots of tables, data, constraints and indices, there will
be variations in the performance from time to time.
It is responsibility of the DBA to tune the database performance.
Backup & Recovery
Proper backup and recovery programs needs to be developed by DBA and has to be
maintained him. This is one of the main responsibilities of DBA. Data should be backed up
regularly so that if there is any crash, it should be recovered without much effort and data
loss.
Documentation
DBA should basically maintain all his installation, backup, recovery, security methods. He
should keep various reports about database performance.
Security
DBA is responsible for creating various database users and roles, and giving them different
levels of access rights.
Database Designers
Logical Database Designers
The logical database designer is concerned with identifying the data (that is, the entities and
attributes), the relationships between the data, and the constraints on the data that is to be
stored in the database.
The logical database designer must have a thorough and complete understanding of the
organization’s data and any constraints on this data.
Physical Database Designers
The physical database designer decides how the logical database design is to be physically
realized.
mapping the logical database design into a set of tables and integrity constraints.
selecting specific storage structures and access methods for the data to achieve good
performance.
Application Developers
Once the database has been implemented, the application programs that provide the required
functionality for the end-users must be implemented. This is the responsibility of the
application developers.
They are the developers who interact with the database by means of DML queries. These
DML queries are written in the application programs like C, C++, JAVA, Pascal etc.
End Users
The end-users are the ‘clients’ for the database, which has been designed and implemented,
and is being maintained to serve their information needs.
Sophisticated Users
The sophisticated end-user is familiar with the structure of the database and the facilities
offered by the DBMS.
Naive Users
These are the users who use the existing application to interact with the database. For
example, online library system, ticket booking systems, ATMs etc
SQL | Creating Roles
A role is created to ease the setup and maintenance of the security model. It is a named group
of related privileges that can be granted to the user. When there are many users in
a database it becomes difficult to grant or revoke privileges to users. Therefore, if you define
roles:
1. You can grant or revoke privileges to users, thereby automatically granting or revoking
privileges.
2. You can either create Roles or use the system roles pre-defined.
Some of the privileges granted to the system roles are as given below:
System
Roles Privileges Granted to the Role
Create table, Create view, Create synonym, Create sequence, Create session,
Connect
etc.
Create Procedure, Create Sequence, Create Table, Create Trigger etc. The
Resource
primary usage of the Resource role is to restrict access to database objects.
DBA All system privileges
Creating and Assigning a Role
First, the (Database Administrator)DBA must create the role. Then the DBA can assign
privileges to the role and users to the role.
Syntax:
CREATE ROLE manager;
Role created.
Arguments
role_name: Is the name of the role to be created
owner_name: AUTHORIZATION: If no user is specified, the user who executes
CREATE ROLE will be the owner of the role. The role’s members can be added or
removed at the discretion of the role’s owner or any member of an owning role.
Permissions
It requires either membership in the fixed database role db_securityadmin or the CREATE
ROLE permission on the database. The following authorizations are also necessary when
using the AUTHORIZATION option:
1. It takes IMPERSONATE permission from that user in order to transfer ownership of a
role to another user.
2. It takes membership in the recipient role or the ALTER permission on that role to transfer
ownership of one role to another.
3. An application role must have ALTER permission in order to transfer ownership of a role
to it.
In the syntax: ‘manager’ is the name of the role to be created.
Now that the role is created, the DBA can use the GRANT statement to assign users to
the role as well as assign privileges to the role.
It’s easier to GRANT or REVOKE privileges to the users through a role rather than
assigning a privilege directly to every user.
If a role is identified by a password, then GRANT or REVOKE privileges have to be
identified by the password.
Grant Privileges To a Role
GRANT create table, create view
TO manager;
Grant succeeded.
Grant a Role To Users
GRANT manager TO SAM, STARK;
Grant succeeded.
Revoke Privilege from a Role
REVOKE create table FROM manager;
Drop a Role
DROP ROLE manager;
Entity-Relationship
Model: Basic Concepts,
Constraints, Keys:
Primary Key, Super
key,
Candidate key, Entity
Types, Entity Sets,
Design issues, Entity-
Relationship Diagram,
Relations,
Relationship types,
Roles and Structural
Constraints, Weak
Entity sets, Extended ER
Features,
Design of E-R Database
Schema, Reduction of
an E-R Schema to
tables.
relational database design using er to relational mapping
Relational database design using ER (Entity-Relationship) to relational mapping involves
translating the conceptual model represented by ER diagrams into a set of relational tables.
Here's a step-by-step process for this mapping:
1. Identify Entities, Attributes, and Relationships:
Review the ER diagram and identify entities, attributes, and relationships. Entities are
represented as tables, attributes as columns, and relationships as foreign keys.
2. Create Tables for Entities:
For each entity in the ER diagram, create a corresponding table in the relational
database.
Each table should have a primary key that uniquely identifies each record.
3. Map Attributes to Columns:
Map each attribute of an entity to a column in the corresponding table.
Ensure that data types and constraints (such as NULLability and data length) are
defined appropriately for each column.
4. Handle Relationships:
Determine how relationships between entities are represented in the relational model.
For one-to-one and one-to-many relationships:
Add the primary key of the parent entity as a foreign key in the child entity's
table.
This foreign key establishes the relationship between the two tables.
For many-to-many relationships:
Create an associative (junction) table with foreign keys referencing both
related entities.
Each row in this table represents a specific instance of the relationship.
5. Normalize the Schema (Optional):
Apply normalization techniques to ensure the relational schema is free from
redundancy and dependency anomalies.
Normalize tables to higher normal forms (such as 2NF, 3NF) if necessary.
6. Review and Refine:
Review the relational schema to ensure that it accurately reflects the structure and
constraints of the original ER model.
Refine the schema as needed based on performance considerations, data integrity
requirements, and other factors.
7. Implement Indexes and Constraints:
Define indexes to improve query performance for frequently accessed columns.
Implement constraints such as primary key constraints, foreign key constraints,
unique constraints, and check constraints to enforce data integrity.
8. Document the Database Schema:
Document the relational database schema, including tables, columns, relationships,
constraints, and indexes.
This documentation helps developers, administrators, and other stakeholders
understand the database structure.
By following this process, you can effectively translate the conceptual model represented by
ER diagrams into a well-designed relational database schema. It's important to maintain
consistency between the ER model and the relational schema to ensure the integrity and
usability of the database.
